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

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



On Tue, Nov 16, 2010 at 09:35:55PM +0100, David Kalnischkies wrote:
> On Tue, Nov 16, 2010 at 15:21, Holger Levsen <holger@layer-acht.org> wrote:
> > as I was asked on IRC, this is how piuparts modifies apt+dpkgs
> > defaults,  "most interestingly" it doesnt install recommends...:
> 
> And that is the reason. (or at least the trigger)
> 
> First of all: I can't reproduce this E:-message, what i can see on the other
> hand is that apt-lenny chooses to remove nautilus-share while apt-squeeze
> doesn't if you disable installation of recommends -- both are equal if you do.
> 
> The (simplified) situation seems to be:
> samba-common splits out samba-common-bin in squeeze and "only"
> recommends it.
> nautilus-share depends on: samba-common-bin | samba-common (<< squeeze)
> 
> At the time APT looks at nautilus-share everything is fine, later it will
> upgrade samba and therefore samba-common "breaking" this dependency
> (for the experts: That are the MarkInstall calls doing).
> Not a problem as long as recommends are installed as these will bring in
> the new -bin package on an other way, but if not the dependency is still
> broken at the time we enter step 2: after upgrading all packages APT
> looks again at each dependency in its problemresolver to resolve
> exactly that: Problems -- apt-lenny has only two options:
> a) step back from upgrading an offending package (held back)
> b) remove the offending package
> 
> 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.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Reply to: