Hi Sébastien, > Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2:
Thanks. I didn't notice that when considering ways to avoid corner cases. > I also think that removing the Provides is not a good idea. The alternative is > provided by the package, and that should be made clear in the dependency > relationships. > I'm sorry but I don't have an ideal solution to the problems we previously > discussed. But IMO it's acceptable to not perfectly deal with the corner case > where only MKL is installed, as long as some warning is displayed. I insist on removing the Provides, even if it looks weird. For sake of debconf correctness, I can't find a better way other than removing it. This is a special situation where we are dealing with non-free blobs. The choice of providing alternative while leaving the Provides field blank is due to debconf correctness -- which is more important than the Provides field since it directly reflects the user's choice. * When there is only libmkl-rt as libblas.so.3 provider, libblas.so.3 is still used as the default implementation EVEN IF THE USER REJECTS TO USE IT AS DEFAULT in debconf dialog. That means when there is MKL, there MUST be another free alternative. However, assigning Provides to MKL may lead to unexpected corner cases where the consideration of debconf dialog turns in vain, because it is not simple to make sure the existence of another free alternative. In a word, MKL itself is non-free alternative to BLAS/LAPACK, and there should be no problem to disallow MKL to satisfy libblas.so.3 / liblapack.so.3 requirement in a dependency tree where there are LOTS OF GPL-licensed software. I'll override it if leaving Provides blank violates policy because legal safety is greater than technological corectness. As a compromise, let's regard MKL as a "non-free" enhancement to free BLAS/LAPACK implementations. An Enhances: field should be nice for us, which alleviates the discomfort of leaving Provides: blank.
signature.asc
Description: PGP signature
