Ticket #373 (new enhancement)
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: |
Description
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:3 Changed 10 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.
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).