Hi all, 2010/9/6 Julien Cristau <jcris...@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… -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimzkfbfigzfq46okyjlji0nq7kldrv_rkdvw...@mail.gmail.com
