[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
abe at debian.org
Wed Aug 24 23:59:47 UTC 2016
Axel Beckert wrote:
> > 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
> * 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.
What probably would help here is a list of (current) error conditions
which should be suppressable via some configuration option.
I really don't want a
which brings back the old, inconsistent behaviour with all its issues.
So let's try to define the exact behaviour needed for automated setups
where package lists might be not 100% fit what's available.
>From my own experience trying to unify package lists for Ubuntu LTS
and Debian Stable releases as much as possible for use with
aptitude-robot, I know of the following cases which can happen and are
considered "ok" to be ignored in such an environment:
* Installation requests for packages which don't exist in the package
* Removal and purge request for not installed or non-existent
* Hold requests for not installed packages.
Any more situations which normally would validate an non-zero exit
code but might be acceptable/ok/wanted in some setups?
I assume that automated reinstallations or downgrades of packages are
rather uncommon in such setups and can be ignored wrt. to suppressing
an non-zero exit code.
,''`. | 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
More information about the Aptitude-devel