On Sun, Jul 07, 2019 at 04:59:03PM +0200, Piotr Engelking wrote: > Salvatore Bonaccorso <car...@debian.org>: > > > I do not think this will be reverted, but time will show. There was > > already an earlier intention to do this to get consistency across the > > archive: > > > > https://lists.debian.org/debian-security/2015/12/msg00015.htm > > > > But back then this was not possible to switch. Then the buster release > > was the optimal point in time to retry: > > > > https://lists.debian.org/debian-security/2019/06/msg00015.html > > > > This quarantees that actually now the archive is in itself more > > consistent and security archive is not anymore a special case for > > future releases. > > > > User will anyway need to update the sources.list when switching to > > bullseye, so the need of touching sources.list makes it as well > > equally easy to then adjust the respective distribution component of > > the URL. > > Change of the URL component to bullseye-security is not a problem. > > The problem is that the bullseye-security Release file sets the > Suite field to testing-security. This interacts badly with commonly > recommended (by, among others, the apt_preferences(5) manual page) > APT pinning configuration of systems running Debian testing: > > Package: * > Pin: release o=Debian, a=testing > Pin-Priority: 800 > > 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. > > > testing-security is only populated very late in the freeze of a > > release, in deep freeze when unblock requests are not anymore possible > > and still packages should be released for security to have them from > > day 0 in the new release. > > This, on one hand, makes fixing the problem not urgent. On another, > it makes users even less likely to discover the problem on their own. > > The solutions I can think of are: > > * Do not do anything. This is leaves systems in a potentially > vulnerable state. This seems the "best" outcome. In any case, we have about 2 years to figure this out and should keep things this way for now. > > * 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. Ubuntu would use: Codename: bullseye Suite: bullseye-security but that would not help you either for a= pins, only for n pins (or ones without an a= or n=). I also find it super annoying as bullseye pins now apply to bullseye-security, and I can't pin bullseye release. It also breaks testing-security as a name. That said, we might want a way to specify more aliases. Having two names for a distribution is severily limiting, especially if we want to allow people to specify versions instead. Maybe we should have more Release file fields (Codename-Alias, Suite-Alias, Alias)? > > * 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. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
