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

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

The problem is not the user expectation in this case. Users seldom looks at all 
the
Depends: field of packages beofre upgraidng them.

The problem is the expectation of the developers that wrote the Depends line:
they expected that the non-free or-group would not replace the free group
unless the user installed the non-free alternative before.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101121201738.gi16...@yellowpig



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

2010-11-21 Thread Russ Allbery
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:

 The problem is the expectation of the developers that wrote the Depends
 line:  they expected that the non-free or-group would not replace the
 free group unless the user installed the non-free alternative before.

As a developer, that's not what I expect.  I expect the non-free
alternative to be installed instead of the free alternative if it's a
better match to the other software that the user has installed on their
system, *provided* that the user has intentionally chosen to enable the
non-free archives on their system, indicating they're okay with that
behavior.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqtynszm@windlord.stanford.edu



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

2010-11-20 Thread Holger Levsen
On Freitag, 19. November 2010, Russ Allbery wrote:
 I believed that because that's what Debian has done for as long as I've
 been involved in it, so I always assumed that was the intended meaning.

You convinced me with this.



signature.asc
Description: This is a digitally signed message part.


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

2010-11-19 Thread Bill Allombert
On Wed, Nov 17, 2010 at 03:44:43PM +0100, Holger Levsen wrote:
 Hi,
 
 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.

 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.

 Bill, so far you're the only one in #587279 objecting to the clarification 
 making the what-you-call strange interpretation crystal clear (and 
 following the way it was always handled).

Nobody in #587279 is saying that the text is ambiguous. This precisely why a
policy change was proposed in the first place.

(the text I am referring to is the package must not declare a Depends,
Recommends, or Build-Depends relationship on a non-_main_ package)

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101119200610.ga16...@yellowpig



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

2010-11-19 Thread David Kalnischkies
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-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=h+ha_x9esu3uxvw3kgjlqroapbktvxsj1q...@mail.gmail.com



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

2010-11-19 Thread Russ Allbery
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
 On Wed, Nov 17, 2010 at 03:44:43PM +0100, Holger Levsen wrote:

 Bill, so far you're the only one in #587279 objecting to the
 clarification making the what-you-call strange interpretation crystal
 clear (and following the way it was always handled).

 Nobody in #587279 is saying that the text is ambiguous. This precisely
 why a policy change was proposed in the first place.

I've always interpreted the current text to mean what the proposed change
says that it should mean, namely that non-default alternatives are okay
but the package cannot depend only on a non-free package.  That's why I
originally was going to commit this as an informative change, since I
didn't think it was a normative change from the previous version of
Policy.

I believed that because that's what Debian has done for as long as I've
been involved in it, so I always assumed that was the intended meaning.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd3t80nv@windlord.stanford.edu



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

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

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  r...@space.bgr...@ringlet.netr...@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.


signature.asc
Description: Digital signature


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

2010-11-17 Thread Bill Allombert
[Debian policy: For reference, this is bug #603680.
On Wed, Nov 17, 2010 at 12:59:00PM +0100, David Kalnischkies wrote:
 On Wed, Nov 17, 2010 at 10:34, Bill Allombert
 bill.allomb...@math.u-bordeaux1.fr wrote:
  On Tue, Nov 16, 2010 at 09:35:55PM +0100, David Kalnischkies wrote:
 [… snip …]
  apt-squeeze recently (see #591882) got a third option:
  c) try installing another or-group member
 
  Note that while c) seems to be the captain obvious solution it introduces
  a big problem: a) and b) reduce the number of broken packages,
  but c) can add a lot more which could (real-world will tell if really)
  work against the current resolver determinism…
 
  Probably option c) should be removed. This makes upgrade process much less 
  predictable.
  An secondary issue with option c) is that this can lead apt to upgrade free
  packages with non-free packages, if non-free packages are listed as 
  alternative.
 
 Only if the free package is uninstallable in squeeze, but in this case a
 new installation has the same result.

Not necessarily: during an upgrade there are much more constraint to satisfy
that during an installation, as this is the case here.

 APT will try to fix the free package before it tries to fix the packages
 depending on the free one, so the non-free option is still only the fallback.

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 issue either.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101117135400.gb22...@yellowpig



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

2010-11-17 Thread Holger Levsen
Hi,

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. 
So I think apt is actually right in those cases to upgrade to a non-free 
alternative. It's the users choice.

Bill, so far you're the only one in #587279 objecting to the clarification 
making the what-you-call strange interpretation crystal clear (and 
following the way it was always handled).


cheers,
Holger



signature.asc
Description: This is a digitally signed message part.