Bug#587279: Bug#603680: libnautilus-extension1: breaks nautilus-share upgrade from lenny
On Fri, Nov 19, 2010 at 21:06, Bill Allombert
<Bill.Allombert@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…
Reply to: