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

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Sat Sep 17 15:13:28 UTC 2016


Hi,

2016-08-25 02:13 Thomas Lange:
>>>>>> On Thu, 25 Aug 2016 01:59:47 +0200, Axel Beckert <abe at debian.org> said:
>
>    > So let's try to define the exact behaviour needed for automated setups
>    > where package lists might be not 100% fit what's available.
>
>    > * Installation requests for packages which don't exist in the package
>    >   lists.
>    > * Removal and purge request for not installed or non-existent
>    >   packages.
>    > * Hold requests for not installed packages.
>
>This is missing:
>Packages which are in the package list, but do not have an
>installation candidate.
>
>
>For me it's OK to have this as a wishlist bug, but it's very
>important, that this option will be implemented for stretch. FAI and
>other automated installation systems did not rely on the bad behaviour
>of aptitude, but the used this behaviour as a usefull feature.
>
>I would love to see a comment from the aptitude/apt-get developers, if
>this new option can be implemented for stretch.

Reverting is not very likely, sorry.  The change was not made late in
the development cycle of the release (as we are now) for a reason.

The option of implementing a config flag for this would maybe make
sense, but I haven't had much time in the last few weeks and I will be
busy for a while yet, so let's see.


>From another message:

> # aptitude install a b c d
>
> and c is a package name which is not known, using this
> option the package c will be removed from the list (or just ignored)
> but packages a, b and d will installed.

An obvious workaround from the caller's side when the given command
fails is to repeat the command with the individual packages, so one can
additionally give feedback to the user ("we wanted to install pkgAwesome
but actually it's not possible!!").

The common case when things don't fail should be fast and more "correct"
when informing about problems.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>



More information about the Aptitude-devel mailing list