Package: aptitude
Version: 0.2.15.9-2
I'm doing a update from what is now oldstable to stable, using Aptitude's
interactive mode. There are a number of cases where Aptitude's dependancy
resolution likes to select packages that are unneeded. Sometimes these
selections even cause packages that were not otherwise broken to be put
in a broken state!
1> It wants to select libwww0. This appears to be from tetex-bin
which depends on libwww0 | libwww-ssl0, however; as libwww-ssl0 is
already selected tetex-bin is non-broken, and as libwww0 and libwww-ssl0
conflict, this moves both of them to a broken state! A further note, an
older version of libwww-ssl0 is already present.
2> Aptitude wants to install xlibmesa-dev, despite the selection of
libglu1-mesa-dev. libgle-dev_3.0.7-2 is installed, and inventor-dev is
selected, but both of those are satisfied by libglu1-mesa-dev. This could
be due to an older version being installed, but that is slated for
removal, and the installation of both would break both.
3> Aptitude also really wants exim4/exim4-base/exim4-config. Likely
this comes through one of a zillion things that recommend or depend on
exim4 | mail-transport-agent. Thing is a *lot* of packages provide
mail-transport-agent (and notably nearly all of those have a far superior
security track record). Due to the installation of other packages which
provide mail-transport-agent, selecting those packages merely puts them
in a broken state!
4> Aptitude's decision to select flex-old due to the recommendation
of bison++. Yet, due to the installation of flex, this selection causes
both to be broken.
This looks like the dependancy resolution code doesn't look far enough
before deciding that a dependancy isn't fulfilled. Notably for #1 I'd
have to guess it is simply finding that the first item in that OR isn't
fulfilled and therefore selecting that without exploring and finding
that the second IS fulfilled.
This seems to suggest that mark-sweep should be used for identifying
broken packages, rather than a graph traversal. This would also take care
of the problem of circular dependancies.
A simple solution would be the one suggested for #149049. I'd tend to
refer to it as Forbidding the installation of a package, but the idea is
the same. As a matter of fact I also agree with the use of '=' for this
purpose and in fact I'd tend to use the "Hold" flag as this also is the
same idea (being held at version zero/"not-installed"). Same issue occurs
with dselect actually. I simply want to tell it DO NOT SELECT THE BLOODY
PACKAGE! I'LL TAKE CARE OF ANY BREAKAGE LATER, AT MY OWN CONVENIENCE!
Sorry about that, because I'm having to take care of this over a number
of sessions it gets annoying after a couple times.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | [EMAIL PROTECTED] PGP 8881EF59 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
