[Aptitude-devel] Bug#835372: Bug#835372: aptitude: behavior change with 0.7.6 with packages that can't be installed breaking automated installations

[Axel Beckert]

Hi Mika,

Michael Prokop wrote:
> This was the expected behavior since ages(tm) with aptitude:
[...]
>   # apt-cache policy aufs-tools
>   aufs-tools:
>     Installed: (none)
>     Candidate: (none)
>     Version table:
>   # aptitude install aufs-tools
>   No candidate version found for aufs-tools
>   No candidate version found for aufs-tools
>   No packages will be installed, upgraded, or removed.
>   0 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
>   Need to get 0 B of archives. After unpacking 0 B will be used.
>   [..]
>   # echo $?
>   0

I strongly disagree that this was "expected" behaviour. There were
quite some bug reports about aptitude exiting with zero despite it
couldn't fulfil the requested action. (See your cited NEWS entry for
such bug reports.)

And yes, sure, it was _known_ behaviour and people lived with it and
worked around it. But it is nevertheless buggy behaviour because it
hides issues and claims that everything is fine.

> Now starting with aptitude 0.7.6 (and it also applies to most recent
> version v0.8.3) we get this behavior instead:
[...]
>   # aptitude install aufs-tools
>   No candidate version found for aufs-tools
>   Unable to apply some actions, aborting
>   # echo $?
>   255
> 
> This seems to be what's documented as follows inside
> /usr/share/aptitude/NEWS:
> 
>   * [cmdline] Abort with Failure when actions cannot be taken
>     (Closes: #121313, #430392, #445034, #498239, #576212, #639789, #798320)

Yes. And it was available in the (uncontinued) experimental 0.6.9
branch, too. These commits were later cherry picked into the main
development branch to finally get this category of bugs fixed for the
average user, too.

> But this actually breaks automated installations, where situations
> like above with non-existing packages might be present and are
> expected or at least accepted.

It at least did not break aptitude-robot -- except for some more mails
by cron, but they can be suppressed via configuration since version
1.4 of autumn 2015.

We have that kind of over-complete package lists at work, too, but
that aptitude bug fix did not break our setup. But due to having run
the (discarded) 0.6.9 experimental branch for quite while, I'm well
aware of aptitude's unreliable exit code for years now.

> Assuming that you don't want to switch back to the previous command
> line behavior please at least consider providing an option
> (APT::Get::...)

You probably meant "Aptitude::…".

I agree that providing such an option for backward compatibility with
the old, broken behaviour shouldn't hurt, especially if there's
software out there which relies on that broken behaviour.

> to not abort with a failure in such a situation, so
> the previous behavior can be restored in tools like FAI through that
> option. (I think this issue *could* actually warrant an RC bug
> severity since that behavior change might bite users in automated
> scripts.)

I'm actually tempted to downgrade this to wishlist as I still think
that

* the current behaviour is correct,
* the previous behaviour was buggy, and
* requesting an option to switch back to the old, broken (or similar)
  behaviour is a feature request and hence of severity wishlist.

If some other software relies on that bug, I consider it a bug in that
software, not in aptitude.

P.S.: The old behaviour was also inconsistent because there was no
clear line between errors which caused aptitude to exit with non-zero
value and errors which were not represented in the exit code. So
relying on such inconsistent behaviour is IMHO even dangerous.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE