Re: Re: Bug#592900: Updating system-config-printer
Hi all,
2010/9/6 Julien Cristau <jcristau@debian.org>:
> On Sun, Sep 5, 2010 at 14:35:39 +0200, Josselin Mouette wrote:
>
>> As for hal-cups-utils, I’ve uploaded the fixed meta-gnome2, which has
>> been sitting in the SVN all the while.
>>
> Looks like that helped, I now get:
[snip]
(Julien and I had discussed it a bit while ago on irc #debian-apt:)
APT itself is perfectly fine updating (and cause of that removing) the
packages - BUT and here is the turning point, if APT really does it
depends on how "broken" the system will be after such an update.
Lets start from the ground, as I already saw wrong options and
opinions based on them in the thread, try the following:
apt-get dist-upgrade -o Debug::pkgProblemResolver=1 -s
Bonus hints:
* run all of it as normal user…
* remove -s and add -o Debug::NoLocking=1 --trivial-only to avoid
the installation order debugging
* try it with a status file from somebody else: -o Dir::state::status=./status
* Debug::pkgDepCache options can be useful if you want to see why
a package is marked for install and mostly to debug autoinstall…
(* you will need at least squeeze APT to see the same as I do)
You will (maybe) see a bunch of lines looking like this one:
Broken python-cupshelpers:amd64 Stört on python-cupsutils [ amd64 ] <
1.0.0-6 > ( python ) (< 1.2.3)
Considering python-cupsutils:amd64 2 as a solution to
python-cupshelpers:amd64 1
Holding Back python-cupshelpers:amd64 rather than change
python-cupsutils:amd64
Thats the key part of the problem resolving:
Packages want python-cupshelpers and python-cupsutils installed,
but in their candidate version they can't co-exist on the system
so APT needs to decide which package is more important than the other.
You can see this decision in line 2: the score is 2 vs. 1 in this case.
As you can see here, python-cupsutils seems to be more important (2)
than python-cupshelpers (1) and therefore APT will retreat from upgrading
so it can keep both packages and everybody (expect you in this case)
is happy as nothing is broken.
How are these scores calculated?
Various attributes of a package influence its score including its priority
(required is more important than optional) as well as how many packages
have a dependency on this package -- if I talk about dependencies I mean
the whole set, in this case Pre-Depends, Depends and Recommends are
considered as in a "normal" system all three should be installed for
perfection.
And yes, even if loosing a Recommend package isn't the end of the world
it breaks functionality of the package which recommends it (otherwise it
wouldn't be recommend, doesn't it?) so unconditional removing it
can't be a good option… and I hope this shows a bit why there is no
"the one and only solution" for a package manager and why even the
unbelievable good aptitude solver can be "wrong" depending on which
values you score higher…
I hope it is also clear now why the drop of a package from Recommends
can have "interesting" effects and how you can look at them, if you care.
(try Debug::pkgProblemResolver::ShowScores=1 to see the complete
scoring list, but beware, it will be many lines long…)
Its btw a good idea to ask for help on the mailinglists the few active APTlers
read instead of crying into the deep woods how broken APT is (maybe)…
Dropping "support" for APT in your package is more or less the worst thing
you can do and shouldn't be even considered as an option for anyone:
While aptitude is maybe the current recommend tool you still have
a lot of users out there using APT for various reasons or are using
applications which are based on APT… and in the end, even aptitude is
based on APT and if all this is not enough of an argument:
Claims like "I doesn't care for APT" are unlikely to motivate anyone to
improve anything (in case they find it out what by accident).
I for one doesn't care for cups as I don't print the internet on dead
trees for a few years now, still I am writing this mail…
A question which i have in mind since i read that the mentioned
packages are not compatible as they are in different namespaces:
Is this breaks just here to remove the package from the system?
If so, thats not the idea behind breaks…
If they are co-installable they should be co-installable,
end-of-support is not an other word for breaking away packages
as it breaks third-party archives as well as self-builds.
Let autoremove and co handle these instead…
Anyway, even long mails come to an end sometimes,
so thanks for all the fish and best regards
David "DonKult" Kalnischkies
P.S.: In case deity@ is dropped feel free to add me to CC…
Reply to: