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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]