[Aptitude-devel] Bug#768047: Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

[Axel Beckert]

Control: severity -1 wishlist

Hi Christoph,

Christoph Anton Mitterer wrote:
> But since you seem to be neither member of the security team

It's correct that I'm no member of the security team.

> (and I guess even that is probably not the ultimate group to decided
> where the security tag applies to)

AFAIK they actually _are_ the ultimate group to decided where the
security tag applies to. But inbetween there comes the package's
maintainer(s)...

> or maintainer of aptitude (or did I miss something),...

It indeed seems as if you missed some facts:
https://alioth.debian.org/project/memberlist.php?group_id=30020

You may also want to have a look at who signed the latest and some
earlier uploads of aptitude: https://tracker.debian.org/pkg/aptitude

And as long as I'm the only aptitude team member who has an opinion
about this bug report, you should consider my opinion as being the
maintainer's opinion -- and respect it accordingly.

> Just because e.g. lcms1 is no longer upgraded in unstable, this
> should mean that aptitude proposes it to downgrade to a "new" older
> version, when a security update comes out.

I disagree. Such a behaviour would be wrong and should be considered a
bug if it appears with the default pinning. Changing aptitude's
behaviour into that direction is solely a job for pinning (you can
enforce downgrades through pinning if you really prefer that) and
hence the local system administrator's job.

The list of upgradable packages is controlled by pinning in similar
ways. And I don't think that aptitude should override pinning (be it
default or local) in any way unless the local admin overrides it
interactively or on the commandline. (Which IMHO is easier to do with
aptitude than with apt.)

Additionally downgrades are officially _not_ supported, even if that
downgrade may fix a security issue. Downgrades may or may not work
(see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764503#12)
and I don't think, aptitude should by default suggest downgrades in a
prominent way unless they are officially supported. And very often
they are also impossible in the setup you described due dependency
conflicts(*).

The security tag is debatable. The said feature may involve security
updates under the circumstances you described. I know that this kind
of setup is not that uncommon(*), but it's still very specific and
especially _unsupported_. I still think we should not tag bug reports
as security if they only involve unsupported setups (unstable with
security updates from stable) and especially if they involve
officially unsupported features (downgrading).

I though agree that having a group showing "newer than in archive"
packages would be a helpful _feature_ in general. The fact that this
feature is not yet there is _not_ a bug and hence it does not deserve
any severity higher that wishlist -- also because you already can
search for according packages or limit the view to them as explained
in my previous mail.

(*) I have two machines with such setup myself. Downgrading
    packages to stable usually leads to dependency conflicts. And
    usually the only viable solution to fix such issues is to
    uninstall the packages in question completely. This counts for
    security updates in stable as well as other stable packages.

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