On 2019-02-20 14:22, Jonathan Wiltshire wrote:
Hi,
On Wed, Feb 20, 2019 at 02:54:55PM +0100, Lucas Nussbaum wrote:
Now, questions:
* what's the relation between debian-security and
stable-proposed-updates? Are packages from debian-security
automatically copied to stable-proposed-updates so that they can
later
be included in the next point release?
Yes.
Well, specifically stable-new (as mentioned in earlier points I elided).
They then get included in point releases iff all builds are available
and installable.
* Are packages in stable-updates copied to stable when stable point
releases happen? (I have the impression that they aren't, but am not
sure)
No, policy is that packages are copied from spu to stable-updates. In
other
words, packages must already be part of a forthcoming point release
(just
as bugs must be fixed in unstable before a stable package is accepted).
Also sort of yes. :-) The package in p-u is copied to stable, and by
definition a package in -updates must have been in p-u.
* What is the logic behind not cleaning stable-updates and
debian-security when stable point releases happen? keep things
around
for people who only have those suites, no 'stable', in sources.list?
Yes. Apparently a very small number of people have sensitive
installations
and consume only security updates, not errata.
For -updates it's a combination of not assuming that people upgrade
immediately after a point release, and a lack of tooling to make things
more automable. We've discussed several times having some form of
automation that could at least present a list of packages in -updates
that are older than stable and could therefore be cleaned up, but for
anything where -updates has the same version as stable I would also want
some form of additional filtering such as "and at least one point
release has passed since that became the case" (or at least "and the
most recent point release was at least X weeks ago").
Regards,
Adam
