Julian Andres Klode <j...@debian.org>: > > Now a=testing packages have higher priority than the a=testing-security > > ones, which results in security updates not being installed. Another > > method of pinning configuration, using APT::Default-Release, has > > exactly the same effect. > > And this is a good thing IMO, as you want to be able to pin release > over security.
Why? Anyway, this was already possible, using l=Debian and l=Debian-Security. > > * Change the suite from a=testing-security back to a=testing. This is > > least work, but I don't know if it has any downsides I am unaware of. > > That means that testing-security does not work, as testing-security is > not testing and apt will complain. Which diagnostics are you talking about? I wasn't able to find it. > > * Change the documentation to work with the current setting, and warn > > the existing users. (In APT::Update::Post-Invoke, perhaps?) This may > > be reasonable, and could be used to warn about other configuration > > problems, like no security updates configured at all. > > This does not seem possible. I don't see how you'd figure out affected > users. No security updates configured: * (o=Debian, a=testing) source * no (o=Debian, a=testing-security) source Security updates configured, but not applied: * (o=Debian, a=testing) source has higher priority than (o=Debian, a=testing-security) source These two are trivial and take care of most configuration problems. Package pins are more complicated. Once it prevents a particular security update, we can detect it reliably, but it may be too late, as some people do unattended upgrades: * the candidate version of a package comes from (o=Debian, a=testing) and is lower than a version from (o=Debian, a=testing-security)
