Dear Maintainer,
Running "aptitude --log-level=debug build-dep mutt" produces:
Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev
Unable to apply some actions, aborting
I see a few bugs here:
1) If I omit "--log-level=debug" I get the same output. So it's
unfortunate that the "debug" logging level does not clear up the
extreme vagueness of the output.
2) The libgpgme11-dev package is already installed. So aptitude
should not even be attempting to install it in the first place.
3) "Unable to satisfy.." is too vague, and also printing
"..build-depends: Build-Depends:.." is redundant.
4) "Unable to apply some actions" is too vague. What actions?
It's also important to point out that apt-get has no problem. That
is, running "apt-get build-dep mutt" shows:
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
comerr-dev krb5-multidev libgnutls28-dev libgnutlsxx28 libgssrpc4 libidn11-dev libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8
libkrb5-dev libncursesw5-dev libnotmuch-dev libp11-kit-dev libsasl2-dev libtasn1-6-dev libtokyocabinet-dev nettle-dev zlib1g-dev
0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,411 kB of archives.
After this operation, 15.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]
and apt-get simply works in this case.
Hi, thanks for the bug report! Nomen Nescio wrote: On a first glance, this looks to me like a duplicate of #509100 (https://bugs.debian.org/509100). Can you please verify that your issue only shows up if there are virtual packages listed in the build-dependencies (or their dependencies), i.e. if aptitude always and only argues about virtual packages? in Debian Stretch as well as in Debian Unstable. Another common thing with #509100. Installation, Removal, Reinstallation, Configuration, etc. Do you know any better term to describe any action on packages? Also common with #509100. Regards, Axel
Package: aptitude Version: 0.8.7-1 Followup-For: Bug #879965 $ aptitude build-dep ledger=2.6.2-3.1 but when I search for "ledger" in /var/log/aptitude and /var/log/apt/*, I find no trace of that action (which I was hoping would reveal which packages were installed as a result). Can you suggest another way for me to get that information? To answer the question w.r.t mutt, I removed all non-virtual packages from the set of packages that apt-get installed: $ aptitude remove comerr-dev krb5-multidev libgnutls28-dev libgnutlsxx28 libgssrpc4 libidn11-dev libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8 libkrb5-dev libncursesw5-dev libnotmuch-dev libp11-kit-dev libsasl2-dev libtasn1-6-dev libtokyocabinet-dev nettle-dev zlib1g-dev The idea is that if only non-virtual packages are needed, then aptitude would have no problems as far as we know. But in fact it still has a problem with the virtual package that was never needed in the first place. That is, running "aptitude --log-level=debug build-dep mutt" still produces: Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev Unable to apply some actions, aborting It seems I've caught aptitude in a lie, which seems to play into this problem: $ aptitude why libgpgme11-dev Not currently installed No dependencies require to install libgpgme11-dev $ aptitude why libgpgme11 i libgpgme-dev Depends libgpgme11 (= 1.8.0-3+b2) $ aptitude show libgpgme-dev Package: libgpgme-dev Version: 1.8.0-3+b2 State: installed Automatically installed: no ... If I can assume that the "Unable to apply some actions" is a final summary statement to tell the user why the high-level operation failed, then it should state what exactly prevented aptitude from printing a "success" message. As I understand it, in the course of handling a request aptitude is doing many tasks, and delegating many tasks to other tools/processes. All those tasks result in warnings, errors, and information, and perhaps in some cases silent failures that yielded no output at all. Aptitude probably doesn't have a practical way of knowing whether the child processes properly informed the user, but it does know specifically what job had what exit status, which is likely how aptitude knew in the first place that there was a blocking failure. It should tell the user "apt-get failed to find a file", for example. It's particularly important in the case of a misbehaving tool (developed externally to the aptitude project) that would fail silently, for example.
Package: aptitude Version: 0.8.7-1 Followup-For: Bug #879965 $ aptitude build-dep ledger=2.6.2-3.1 but when I search for "ledger" in /var/log/aptitude and /var/log/apt/*, I find no trace of that action (which I was hoping would reveal which packages were installed as a result). Can you suggest another way for me to get that information? To answer the question w.r.t mutt, I removed all non-virtual packages from the set of packages that apt-get installed: $ aptitude remove comerr-dev krb5-multidev libgnutls28-dev libgnutlsxx28 libgssrpc4 libidn11-dev libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8 libkrb5-dev libncursesw5-dev libnotmuch-dev libp11-kit-dev libsasl2-dev libtasn1-6-dev libtokyocabinet-dev nettle-dev zlib1g-dev The idea is that if only non-virtual packages are needed, then aptitude would have no problems as far as we know. But in fact it still has a problem with the virtual package that was never needed in the first place. That is, running "aptitude --log-level=debug build-dep mutt" still produces: Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev Unable to apply some actions, aborting It seems I've caught aptitude in a lie, which seems to play into this problem: $ aptitude why libgpgme11-dev Not currently installed No dependencies require to install libgpgme11-dev $ aptitude why libgpgme11 i libgpgme-dev Depends libgpgme11 (= 1.8.0-3+b2) $ aptitude show libgpgme-dev Package: libgpgme-dev Version: 1.8.0-3+b2 State: installed Automatically installed: no ... If I can assume that the "Unable to apply some actions" is a final summary statement to tell the user why the high-level operation failed, then it should state what exactly prevented aptitude from printing a "success" message. As I understand it, in the course of handling a request aptitude is doing many tasks, and delegating many tasks to other tools/processes. All those tasks result in warnings, errors, and information, and perhaps in some cases silent failures that yielded no output at all. Aptitude probably doesn't have a practical way of knowing whether the child processes properly informed the user, but it does know specifically what job had what exit status, which is likely how aptitude knew in the first place that there was a blocking failure. It should tell the user "apt-get failed to find a file", for example. It's particularly important in the case of a misbehaving tool (developed externally to the aptitude project) that would fail silently, for example.