Bug 529342 – =dev-perl/DateTime-TimeZone-1.810.0: please stabilize

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description nE0sIghT 2014-11-15 15:21:09 UTC]

Created attachment 389408 [details, diff]
Patch against DateTime-TimeZone-1.600.0.ebuild

All dev-perl/DateTime-TimeZone packages have bundled pre-compiled perl modules for each timezone. These modules generated by bundled tool "parse_olson".

Latest in-portage dev-perl/DateTime-TimeZone-1.640.0 bundles modules generated from tzdata-2013h that is very outdated.

I'm attached patch against DateTime-TimeZone-1.600.0.ebuild to recompile bundled modules against latest stable [in Gentoo] tzdata-2014i.

Updated ebuild also available in vortex overlay: https://github.com/nE0sIghT/vortex-overlay/blob/master/dev-perl/DateTime-TimeZone/DateTime-TimeZone-1.600.0-r1.ebuild

[Comment 1 Mikle Kolyada (RETIRED) 2014-11-15 21:27:13 UTC]

It is ugly solution, to be honest. There is version 1.79 I belive this release contains a fix. I will add it soon.

[Comment 2 nE0sIghT 2014-11-16 07:33:42 UTC]

(In reply to Mikle Kolyada from comment #1)
> It is ugly solution, to be honest. There is version 1.79 I belive this
> release contains a fix. I will add it soon.

Version 1.79 contains time zone modules from tzdata-2014j: http://cpansearch.perl.org/src/DROLSKY/DateTime-TimeZone-1.79/lib/DateTime/TimeZone/Europe/Moscow.pm

So no problems with just bumping version

[Comment 3 Christian Ruppert (idl0r) 2014-11-16 13:13:38 UTC]

I'd vote for re-generating the data during merge.

[Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) 2014-11-16 22:39:11 UTC]

I feel changing the built data so that the installed version differs from upstream might result in support problems if people are working with upstream.

ie: 

"I have blah blah problem with timezones, I'm using Foo::Bar 1.2"

"Thats weird, that shouldn't be happening, that was fixed in 1.2"

<much later>

"Oh, turns out I'm regenerating the tzdata myself because gentoo think thats a good idea".

=> DateTime::TimeZone is more or less assuming certain things about what it ships with.

However, if you wish to have a flag like USE="system-tzdata" that adds some kind of tzdata dep and regenerates it from that, I'm not opposed. It lets users keep the pieces.

But having the ebuild itself define what upstream tzdata is used in the ebuild itself might be a bad idea for maintenance reasons. The worst that could happen is somebody might bump the ebuild version, but _not_ the tzdata version, which will in practice give users an ebuild *claiming* to have newer tzdata, but in fact, having the same tzdata.

[Comment 5 Mikle Kolyada (RETIRED) 2015-01-30 11:43:51 UTC]

lets wait a couple of days before fixed version goes stable

[Comment 6 Mikle Kolyada (RETIRED) 2015-02-07 02:23:50 UTC]

Arches, please test and mark stable:

=dev-perl/DateTime-TimeZone-1.810.0

target KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"

[Comment 7 Jeroen Roovers (RETIRED) 2015-02-07 11:38:47 UTC]

Stable for HPPA.

[Comment 8 Mikle Kolyada (RETIRED) 2015-02-18 10:51:27 UTC]

Stable for all.