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.
> 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.
* 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.
* 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.
