Control: retitle -1 Status grouppolicy miscategorizes security updates by only looking at the hostname, not at the Release file (e.g. via apt-proxy) Control: found -1 0.6.11-1 Hi, Raphael Hertzog wrote: > On Fri, 17 Oct 2014, Cedric Knight wrote: > > For wheezy, security updates appear the "Security Updates" section of > > the main view of the aptitude package manager. However, on servers > > using "deb http://ftp.uk.debian.org/debian/ squeeze-lts main contrib", > > security updates are not distinguished from other "Upgradable > > Packages", which is a bit confusing. > > > > Is there any way to get them listed under "Security Updates"? No. > I don't know exactly what criteria aptitude is using to sort those > updates so I can't really tell you. I'm putting the aptitude developers > in copy so that they can reply. Thanks. Aptitude uses what "apt-cache policy" shows (well, not literally). From "apt-cache policy"'s output: Debian Squeeze Security: 500 http://security.debian.org/ squeeze/updates/main i386 Packages release v=6.0,o=Debian,a=oldstable,n=squeeze,l=Debian-Security,c=main origin security.debian.org Debian Squeeze LTS: 500 http://debian.ethz.ch/debian/ squeeze-lts/main i386 Packages release v=6.0-lts,o=Debian,a=squeeze-lts,n=squeeze-lts,l=Debian,c=main origin debian.ethz.ch aptitude looks for the string "security.debian.org" in there and it isn't anywhere in the LTS Release file. The according code is in src/pkg_grouppolicy.cc: // Stolen from apt-watch: /** Tests whether a particular version is security-related. * * \return \b true iff the given package version comes from security.d.o */ static bool version_is_security(const pkgCache::VerIterator &ver) { for(pkgCache::VerFileIterator F=ver.FileList(); !F.end(); ++F) if(string(F.File().Site())=="security.debian.org") return true; return false; } > Depending on how it's implemented, it might be doable by adjusting the > contents of the squeeze-lts Release file. Otherwise it might need a fix > in the aptitude codebase. So it's the latter as "security.debian.org" is hardcoded _and_ it's the origin which seems the hostname from the sources.list (i.e. it will break anyways if you use a non-official security mirror like e.g. the one at http://mirror.hetzner.de/debian/security -- Especially modifying the Release file itself won't help at all. I was about to document this in a bug report, but there is actually already one: https://bugs.debian.org/328620 -- Cc'ing it. It should be updated accordingly with this mail. But then again -- should we really declare Squeeze LTS updates as security updates? I don't think so. They were announced as not being equivalent, the "S" in "DLA" is missing, there's no more distinction between security- and non-security-updates (AFAIK), etc. I also don't recommend to not change the current setup significantly during the squeeze-lts cycle to not mess with people's already established setups. It's merely something which we should think about for wheezy-lts to make it better there. > We have a similar problem with unattended-upgrades which will not detect > those updates as security updates because the repository label doesn't > contain the word security IIRC. Michael, is that something that you wish to > fix with a squeeze-lts upload? Or is that something that we should fix > by updating the squeeze-lts release file? (Ccing ftpmasters so that all > involved parties can voice their opinion) I don't think that's needed anymore either -- currently there is no more distiguishing between security updates and (old)stable minor updates. So either apply them all automatically or none. Regards, Axel -- ,''`. | Axel Beckert <abe@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
Attachment:
signature.asc
Description: Digital signature