[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

[Axel Beckert]

Hi again,

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
> 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.

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
--show-broken-exit-code-behaviour-of-older-aptitude-releases switch
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
  lists.
* Removal and purge request for not installed or non-existent
  packages.
* 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.

		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