[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#603680: Bug#587279: Bug#603680: libnautilus-extension1: breaks nautilus-share upgrade from lenny



On Fri, Nov 19, 2010 at 10:26:37PM +0100, David Kalnischkies wrote:
> 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.

Hmm, what about this, admittedly slightly contrived, but still possible
case:

1. A package, at installation time, depends on free1 | free2 | non-free

2. With time, free1 either stops to provide the needed functionality or
   is simply removed; the next version of the package now depends on
   free2 | non-free

3. At this point, a user tries to upgrade the original package, but on
   her system there is a package that conflicts with free2... the only
   choice for APT now is to install the non-free package.

G'luck,
Peter

-- 
Peter Pentchev	roam@space.bg    roam@ringlet.net    roam@FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
because I didn't think of a good beginning of it.

Attachment: signature.asc
Description: Digital signature


Reply to: