timezone data packaged separately and in volatile?

[Lionel Elie Mamane <lmamane@debian.org>]

Hi,

I just realised that the timezone data in glibc is taken from an
upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data
sometimes changes, more rapidly than our release cycle (and than any
release cycle we can reasonable have).

Examples include the Cuba "no stop to daylight saving" nearly
last-minute change in November 2005 (affecting changes effective
1 October 2005) or the upcoming Indiana changes (to be effective in
April 2006) that got into the database on 30 January 2006.

Currently, for these changes to propagate to Debian, these delays
occur:

 - upstream glibc synchronises with their upstream (this took about
   month and a half for the Cuba example).

 - glibc release (or Debian packages CVS snapshot or Debian glibc
   patched for newer upstream upstream release)

 - Debian packages glibc release, with all portability issues and
   all.

 - Debian release

What I propose, due to the somewhat tight schedule sometimes in play:

 - Package the timezone data as a separate (source+binary) package
   tzdata, directly from glibc's upstream.

 - Put that package in volatile.debian.net .

This would allow updating the timezone data, that is subject to
short-delay political changes, independently from the sensitive
libc6{,.1} package. And thus have it in volatile :)

The tzdata package could be the only source of timezone data (and
libc6{,.1} would depend on it, it would be required, essential) or
libc6{,.1} could still ship its copy, which would be diverted by
tzdata and replaced by its newer copy. In the second scenario, I'd
imagine tzdata to be of priority important or standard and installed
by default on new installs (maybe suggested / recommended by
libc6?). Probably making it simple and taking the first solution would
be best.


libc6 currently "Replaces: timezone, timezones", which suggests that
we were doing something like that before but we moved away from this
solution. Why?


The Debian glibc maintainers seem to sometimes go to a newer-than
upstream tzdata release in the Debian patch.


Is there any issue I'm missing? Thoughts?


-- 
Lionel Elie Mamane