Martin Schulze <[EMAIL PROTECTED]> writes: > Please see the thread summarized in > <http://www.debian.org/News/weekly/2002/29/>: > > Policy for Woody Point-Releases. [4]Several [5]developers [6]would > [7]like to add new packages and updates to their packages to the > recently released stable distribution of Debian. Adding new packages > and random updates to the stable distribution, however, would nullify > the entire idea of having a stable release, Joey [8]explained. Hence, > the same policy as before will be used for point-releases of woody.
Yes, but how does this apply to a package that does nothing but conflict with existing packages? (As is the case with most of the harden-* packages) Agreed, _random_ updates would be a bad thing. However, what the maintainer is proposing here is updates that are driven by DSAs. Although I find it a slight stretch, one could easily argue that the updates to the harden-*flaws packages are security updates. These updates share another feature with security updates. Imagine the package netostrich, which helps you bury your head in the sand remotely. Now, suppose the upstream authors discover a flaw in the 2.0 series of netostrich prior to version 2.33 which allows random network users to bury other people's heads in the sand. Sarge soon contains 2.34 with the security fix, yet woody contains 2.29.1 with a backported fix. Then there would similarly need to be two harden-remoteflaws; one for woody, which conflicts with netostrich prior to 2.29.1, and one for sarge, which conflicts with netostrich prior to 2.34. The harden-*flaws update has to be backported along with the backported fix to netostrich. Now, if we want the harden-remoteflaws package to be at all useful, it needs to be updated along with DSAs... Hrm. The more I think about this the more I wonder if maybe the harden-*flaws packages make much sense in stable at all. If someone is apt-get'ing from security.debian.org, they're already replacing vulnerable versions with fixed ones. If someone is updating from a point release CD, the same thing applies. The only case where I can see it making sense is with someone following testing with most of their packages on hold (they really want a stable system, and only upgrade a package when they need to). Am I missing a scenario?