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 <[email protected]>, 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 _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
