Ticket #373 (new enhancement)

Opened 11 years ago

Last modified 6 years ago

figure out how to tell apt to reattempt to satisfy recommendations

Reported by: geofft Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


If a recommendation isn't satsifiable when a package is installed, as far as I know, apt never reattempts to satisfy the recommendation. We should figure out how to make it do so, so that recommendations for uninstallable/unavailable packages in e.g. debathena-thirdparty get pulled in automatically when upstream fixes their problems, without us having to move that package to a dependency.

This is important if we want to at least halfway attempt to make debathena-thirdparty useful on multiple releases or even arches; there will be packages that we cannot make hard dependencies of -thirdparty.

This is also important if we want all of debathena-thirdparty to be recommendations: see also #372.

Change History

comment:1 Changed 11 years ago by geofft

This is not the perfect answer, but aptitude search '~RBRecommends:~i' will tell you which packages are recommended by an unsatisfied recommendation of any installed package. On the cluster system I'm using, the five listed except gnome-user-guide-en are (known) warts of debathena-thirdparty; gnome-user-guide-en is perfectly installable and I'm not entirely sure why it isn't.

One way to work around this bug would be to run that search before and after each auto-update, see if any packages got added to the list, and try to install the new ones (but don't fail if you can't).

comment:2 Changed 11 years ago by jdreed

  • Milestone set to The Distant Future

comment:3 Changed 6 years ago by jdreed

So, one problem with that query is that it deals poorly with disjunctions. For example, a whole bunch of packages want a readline editor. So one package might Recommend rlwrap, another ledit | readline-editor, and another rlwrap | readline-editor. Now both ledit and rlwrap show up in aptitude's output (as well as readline-editor, but it's a virtual package and we can strip those from the output). Which one do we install, and how do we decide? And, how do we programmatically determine they're both readline editors? Now, we can just give up and install everything, of course. But I think rather than have auto-update deal, I'd rather figure out why this is happening and if we care. The big rewrites of -athena-libraries and -thirdparty seem to have mostly mitigated this. On a current trusty cluster machine, I see exactly 2 broken recommendations: libatm1 from iproute2, and libctl-dev (thirdparty-simulation Depends mpb Depends libctl3 Recommends libctl-doc which Recommends libctl-dev). The iproute2/libatm1 is... weird, but that's upstream's problem, not ours. As for the second one, I have absolutely no problem with APT deciding not to install a Recommendation of a Recommendation of a Dependency.

I'm going to WONTFIX this unless someone convinces me not to.

Note: See TracTickets for help on using tickets.