Re: timezone data packaged separately and in volatile?
Martijn van Oosterhout writes ("Re: timezone data packaged separately and in volatile?"):
> The requirements for getting into a stable release update are not
> black magic, they're quite well known:
2. The package fixes a critical bug which can lead into data loss,
data corruption, or an overly broken system, or the package is broken
or not usable (anymore).
That seems to be true in this case. I think a system which gets the
clock wrong in this way is `overly broken'.
There doesn't seem to be anything in those rules which allows for an
analysis of the risk, so that it can be compared to the benefit.
(Perhaps that's implicit, although it's not stated.) A timezone
update, carefully built against the right dependencies, could be
diffed (that is, the .deb could be diffed) against the old version and
carefully tested, which would provide us with confidence that the new
package is right to install.