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

[Michael Prokop]

Package: aptitude
Version: 0.8.3-1
Severity: important

This was the expected behavior since ages(tm) with aptitude:

  # aptitude --version
  aptitude 0.7.5
  [...]
  # 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

Now starting with aptitude 0.7.6 (and it also applies to most recent
version v0.8.3) we get this behavior instead:

  # aptitude --version
  aptitude 0.7.6
  [...]
  # 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)

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

To provide an example for such a use case: the Grml.org live system
has daily ISO builds using grml-live and its underlying FAI
software. Now with aptitude version >=0.7.6 whenever a single Debian
package is missing in the Debian archive (like with aufs-tools in
Debian/testing in the above example) the ISO can't be generated at
all because the aptitude command fails hard. (JFTR, the validation
about the package installation state takes place at a later stage in
the ISO build process. For expected but non-present packages this
marks the build as unstable instead of stable, but it does *not*
fail the build.)

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

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160825/263a1432/attachment.sig>