dgettext("Carnival", "Helau"),
On Fri, Feb 06, 2015 at 07:05:42PM +0100, Niels Thykier wrote:
> $ apt-get -y install dpkg apt
> [... tons of debug output ...]
Well, as the one who asked for all this output to be generated, let me
say that I am happy about it as it means that the following is curtsy of
just reading and skipping over these lines rather than taking hours to
get this reproduced. Its all a matter of knowing what they actually
mean of course. Someday I should give a course… but enough pre-text,
lets start with what I usually do for dist-upgrades in these kind of
situations:
Looking at the very last cage-fight at the very end of the log:
> Investigating (9) network-manager [ amd64 ] < 0.9.4.0-10 -> 0.9.10.0-5 > ( net )
> Broken network-manager:amd64 Depends on libpam-systemd [ amd64 ] < none -> 215-10 > ( admin )
> Considering libpam-systemd:amd64 0 as a solution to network-manager:amd64 6
> MarkKeep network-manager [ amd64 ] < 0.9.4.0-10 -> 0.9.10.0-5 > ( net ) FU=0
> Holding Back network-manager:amd64 rather than change libpam-systemd:amd64
The involved package names should raise some alarm bells.
So, lets just look for "Investigating" lines about libpam-systemd… and
so fort further up the dependency tree stepping over things like
systemd, gdm3 and gnome-shell which is rather telling in terms of how
easy it is to upgrade dpkg (and apt) first… anyway, we arrive at
something which isn't a broken depends:
> Investigating (1) evolution-data-server [ amd64 ] < 3.4.4-3+deb7u1 -> 3.12.9~git20141128.5242b0-2+b1 > ( gnome )
> Broken evolution-data-server:amd64 Breaks on libebook-1.2-13 [ amd64 ] < 3.4.4-3+deb7u1 > ( libs ) (< 3.6)
> Considering libebook-1.2-13:amd64 53 as a solution to evolution-data-server:amd64 19
> MarkKeep evolution-data-server [ amd64 ] < 3.4.4-3+deb7u1 -> 3.12.9~git20141128.5242b0-2+b1 > ( gnome ) FU=0
> Removing evolution-data-server:amd64 rather than change libebook-1.2-13:amd64
> MarkDelete evolution-data-server [ amd64 ] < 3.4.4-3+deb7u1 -> 3.12.9~git20141128.5242b0-2+b1 > ( gnome ) FU=0
What is not to love about breaking away libraries. I haven't looked at if
this is really needed, but for that package it seems like a common
idiom, so I will pretend it is needed and let it slide, gnome people can
figure this out if they have/want to.
From there up, it only goes further downhill as it all becomes more and
more surreal and we are just looking at a simple install command and not
dist-upgrade where I am supposed to see all this, so what the hell apt?
Lets restart our effort and start from the very top of this apt call:
The various "MarkInstall" and "Installing" lines showcase the dependency
tree. You see, the tree is pretty large thanks to the various 'Breaks'
dpkg has, but looking closer tells you that the huge subtree belongs to
'cups'. In this tree, the biggest subtree is for 'init-system-helpers'
which brings along a new perl and suddenly all makes sense.
perl has an interesting provides thing going which apt fails to make
proper sense of as it fails to see that with upgrading perl-base the
old api disappears, so you basically have to upgrade everything depending
on this old api as well (aka: The tree is way too small, it should
include all the packages we encountered in our bottom-up approach).
It starts to realize this 'too late' which is showcased by the
'Re-Instated' lines – in case you scrolled a bit further up after I gave
up in the first attempt – and results in the resolver painting itself in
a corner stuck somewhere in the middle of the perl upgrade trying to
make the rest of the system deal with it (failing bigtime of course).
I guess we could make this "broken by provides disappearing" more
explicit in dependencies with a bunch of breaks for jessie and I will
see what I can do to fix this for apt/stretch, but this is missing the
point really as all this would achieve is allowing apt to find
a solution for this install request which is very similar to
a dist-upgrade request…
… which is exactly what we didn't want to have here. Our goal was to
upgrade apt and dpkg to jessie first before attempting the big step,
rather than doing everything in this install command as we could just
have run dist-upgrade then.
So, the solution to this is not in apt, nor is it an apt problem per-se.
If you decide that this "upgrade first" scenario isn't of interest this
is a non-issue. Everyone should just do a "apt-get dist-upgrade" and be
done. If on the other hand you want to make this scenario feasible we
have to trim the tree somewhere. I haven't really given this much
thought as I lack the time to test this, but I think the best cutting
point might be the cups-daemon -> init-system-helpers depends (no,
I have no idea how it is used nor if this is feasible). In fact, might
even be better to get init-system-helpers installable on wheezy (aka not
depending on perl-base/jessie) as this solves the problem for other
daemons as well as I have to note that dpkg has (again) a lot of
breaks/conflicts, so there might be other fun trees hidden here making
this "upgrade first" scenario rather fragile/useless if not tested
properly (which was why I expressed my doubts about this in the first
place).
Best regards
David Kalnischkies
P.S.: 'install' and 'dist-upgrade' have a very different approach to
solving, so I am not very surprised that 'install' fails to do it and
I doubt that problems seen in the bottom-up approach can be seen in
a dist-upgrade - mostly as the cage-fight scores will be different.
Attachment:
signature.asc
Description: Digital signature