On Fri, Nov 19, 2010 at 21:06, Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> wrote: > On Wed, Nov 17, 2010 at 03:44:43PM +0100, Holger Levsen wrote: >> if you intend to reply to this subthread, please use the 587279 bug. > >> On Mittwoch, 17. November 2010, Bill Allombert wrote: >> > I do not think it is correct to ever upgrade a free package to a non-free >> > one. Now, apt is not at fault, the problem rather lie in a strange >> > interpretation of policy 2.1.2 by some developers. But we cannot ignore the >> 2.2.1 >> > issue either. >> >> No. The "problem" lies in people adding non-free and contrib to their >> sources. > > I disagree. I put non-free in my source.list so that 'apt-cache show' > displays the > non-free packages, not to get any of them installed. This is important for > reporting > bugs against non-free packages, and not breaking them inadvertently.
You are free to pin the source to -1 by default and only promote packages you like to a higher pin or vise versa, pin the specific packages you don't like down to -1 (= APT doesn't allow this version to be a candidate) >> So I think apt is actually right in those cases to upgrade to a non-free >> alternative. It's the users choice. > > There are a variety of licenses in non-free and a user (or their lawyers) can > be > fine with some of them but not all. The choice of non-free packages installed > should remain with the users. > Now apt is just a tool and I do not ask apt to be aware of non-free. However > the > change in apt make the non-respect of policy 2.2.1 more problematic. I still fail to see why. How can it be more problematic to install alternative B if (and only if) alternative A is not installable? I don't think that a user expects that APT ignores or-groups and just always only works with the first package in the or-group and fails if it doesn't work out with it. It does work for ages if you install the package - so why must the situation be different if the package is upgraded? Please give an example why - or at least get your terms straight, as its problematic to follow an "upgrade a free package to a non-free" argument as it doesn't make sense: A single package is in a specific version either free or non-free, if it changes his freeness-status between different versions is a completly different "problem"… You seem to want to make the point that a free-dependency shouldn't be replaced by APT with a non-free-dependency and my answer is that it will not as long as the free-dependency can be used - in case the or-group is free | non-free, of course. Your turn. And remember, in a stable environment A can't be not installable (at least if the user hasn't actively choosen to not install it: hold, -1 pin, …) so whatever you might come up with seems to be only possible in unstable - as testing has also protection layers against uninstallability… Best regards David Kalnischkies P.S.: And i don't see why free | non-free doesn't respect the policy. The package doesn't depend on non-free stuff. It can work as well great with free stuff. In fact, as free is ordered first it will likely work even better with free. non-free is just an alternative nobody needs to choose, its just allowed for the poor souls using and/or allowing non-free stuff… -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
