aptitude returns 0 exit status code even if the requested action is not successful

[Thomas Nygreen]

I have experienced two cases where aptitude returns a 0 exit status code, even if it prints error messages to the terminal.

Case 1: A package cannot be installed due to unmet dependencies.
Example: (installing something that depends on sun-java on a host with the "partner" repository disabled)

    > sudo /usr/bin/aptitude -y install hadoop-0.20
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Reading extended state information
    Initializing package states... Done
    The following packages are BROKEN:
      hadoop-0.20
    The following NEW packages will be installed:
      hadoop-0.20-native{a} liblzo2-2{a}
    0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
    Need to get 41.2MB of archives. After unpacking 92.3MB will be used.
    The following packages have unmet dependencies:
      hadoop-0.20: Depends: sun-java6-jre which is a virtual package.
                   Depends: sun-java6-bin which is a virtual package.
    The following actions will resolve these dependencies:

    Keep the following packages at their current version:
    hadoop-0.20 [Not Installed]
    hadoop-0.20-native [Not Installed]

    Score is -9868

    Writing extended state information... Done
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Reading extended state information
    Initializing package states... Done

    > echo $?
    0

Expected result: Non-zero exit status code

Case 2: The package name does not exist
Example:
   > sudo aptitude install bogus-package
   Reading package lists... Done
   Building dependency tree
   Reading state information... Done
   Reading extended state information
   Initializing package states... Done
   Couldn't find any package whose name or description matched "bogus-package"
   Couldn't find any package whose name or description matched "bogus-package"
   No packages will be installed, upgraded, or removed.
   0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
   Need to get 0B of archives. After unpacking 0B will be used.
   Reading package lists... Done
   Building dependency tree
   Reading state information... Done
   Reading extended state information
   Initializing package states... Done

   > echo $?
   0

Expected result: Non-zero exit status code

[Daniel Hartwig (wigs)]

The inclusion of "-y":

    > sudo /usr/bin/aptitude -y install hadoop-0.20

means that in the event of problems you are instructing aptitude to proceed with it's first suggestion:

    Keep the following packages at their current version:
    hadoop-0.20 [Not Installed]
    hadoop-0.20-native [Not Installed]

*technically* aptitude has done what you have asked it to do.

The problem resolver does attempt to honour explicitly requested actions [1]. In this case that is not possible. The only solution would be to add a further option *requiring* the requested actions to be performed (this is very different to what "-y" does).

[1] Configuration items: Aptitude::ProblemResolver::PreserveManualScore and Aptitude::CmdLine::Request-Strictness

    > sudo aptitude install bogus-package
    ...
    > echo $?
    0

This has already been reported [2].

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590686

[Thomas Nygreen (nygreen-gmail)]

Well, in the case of failing dependencies, it seems like any choice at the prompt gives a 0 return value. Is the rationale that 'aptitude managed to abort successfully' equals success? If that is the intended functionality, then I cannot trust aptitude to give any meaningful return value.

And as far as I can see, the bug you refer to only concerns failing to install a specified version. At least that's what it patches.

[Daniel Hartwig (wigs)]

> Well, in the case of failing dependencies, it seems like any choice at
> the prompt gives a 0 return value. Is the rationale that 'aptitude
> managed to abort successfully' equals success? If that is the intended
> functionality, then I cannot trust aptitude to give any meaningful
> return value.

In choosing to abort at the prompt the return value of 0 should be considered a bug. Other choices made at the prompt have the effect of changing your instructions, and thus, if the new request succeeds, the return value should indicate that.

> And as far as I can see, the bug you refer to only concerns failing to
> install a specified version. At least that's what it patches.

Both case 2 in the OP and the case in the mentioned Debian bug report
are symptoms of the same underlying problem: failure to find the
specified installation candidate.

[Daniel Hartwig (wigs)]

commit a88745bf22c3e83e5d78331a69f813e451c895a0
Author: Daniel Hartwig <email address hidden>
Date: Tue Jun 12 18:19:47 2012 +0800

[Marshall McMullen (marshall-mcmullen)]

I'm still seeing this exact problem on ubuntu 13.04. So I don't see how this is fixed. Observe:

# sudo aptitude install packagedoesnotexist
Couldn't find any package whose name or description matched "packagedoesnotexist"
Couldn't find any package whose name or description matched "packagedoesnotexist"
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

# echo $?
0

[Daniel Hartwig (wigs)]

On 20 June 2013 13:41, Marshall McMullen <email address hidden> wrote:
> I'm still seeing this exact problem on ubuntu 13.04. So I don't see how
> this is fixed.

‘Fix Committed’ and ‘Fix Released’ are different; there is no claim
that this is fixed in Ubuntu.

This particular issue is resolved in an experimental development
branch that has not yet been ported to the mainline.