Bug#707871: pu: package libdatetime-timezone-perl/1:1.58-1+2013c
On Thu, 2013-05-23 at 00:06 +0200, gregor herrmann wrote:
> On Wed, 22 May 2013 22:40:57 +0100, Adam D. Barratt wrote:
[...]
> > > > > I'd like to upload libdatetime-timezone-perl/1:1.58-1+2013c to s-p-u
> > > > ACK, targeting wheezy in changelog, of course.
[...]
> > > > > (and also have it moved to stable-updates if possible).
> > > > (not sure about that one.)
> > > (Let's hope it's possible but up to the RT.)
> > What's the net effect of having the old version in stable for another
> > few weeks? (i.e. the rationale for -updates in advance of 7.1.)
>
> Looking at
> https://mm.icann.org/pipermail/tz-announce/2013-April/000011.html
> (tzdata2013c release) it looks like DST in Palestine (Asia/Gaza) is
> already in effect which wasn't in 2013b, so this seems to have a
> concrete effect, if I'm reading this correctly. - Not sure if this
> warrants going through -updates now, or what the situation for tzdata
> is in this respect.
We've generally pushed tzdata via -updates when there's been a change
which takes effect in the near future or recent past, particularly when
that change was made at short notice (there have been a few "we're
changing to DST next weekend" type announcements). In that context,
maybe we should be considering pushing 2013c for the Palestine / Gaza
changes.
> In general, my idea was to handle libdatetime-timezone-perl like
> tzdata in the past for the wheezy lifetime, i.e. to try to provide
> recent versions (of the data part only) through stable-updates. --
> But I realize this hasn't been discussed with the release team yet :)
Ah, I see. :-) If the changes are only likely to consist of replacing
the data files then yes it should be feasible to update libdt-tz-perl
similarly in tzdata; it might make sense to try and update both packages
around the same time.
Regards,
Adam
Reply to: