On Sun, Oct 26, 2008 at 09:54:26PM +0100, Thomas Viehmann wrote: > X-Debbugs-CC: [EMAIL PROTECTED] > Severity: serious > Package: libtzinfo-ruby > Version: 0.3.10-1 > > Hi Roberto, > > unfortunately, Damián's mail does not seem to have been sent to > -submitter and escaped the ftpmaster evaluating the package. > Thanks for letting me know.
> Can you please make sure that a solution for tzinfo in Ruby is found
> that does NOT duplicate the timezone data, neither in the source nor
> binary packages?
> If it cannot be done with the current scheme, upstream needs to come up
> with a way better way of packaging this. It's silly to take any database
> and compile it into programs.
>
Hmm. I will get in touch with upstream and see what changes can be
made.
> Kind regards
>
> T.
>
> -------- Original Message --------
> Subject: Please don't include yet another copy of tzdata in the archive
> Date: Tue, 7 Oct 2008 11:51:14 -0300
> From: Damián Viano <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> (CCing ftpmaster so they don't miss this bit)
>
> Hi,
>
> Please, make your package use the system timezone.
>
> "The tz database is compiled into Ruby modules which are packaged in
> the release. No external zoneinfo files are required at runtime."
>
> That really isn't a feature in Debian, it's needless duplicating tzdata
> information (which is always installed since libc6 depends on it) with
> the associated maintenance burden.
>
> We already gone trough this with:
>
> php #447174
> postgresql #458927
> python-tz #416202
>
> And still have to deal with:
>
> java 474595
>
>
> Please don't add your package to the list.
>
> I hate to have to vote for rejecting a package, but I really think is
> for the best. I know some ruby so if you need help with a patch or
> something, just mention it in this bug.
>
> Thanks for taking this in consideration.
>
> Damián Viano(Des).
>
I was not aware of what a problem this is/was. The primary motivation
for packaging libtzinfo-ruby is for libactivesupport-ruby. In fact, I
have an update to libactivesupport-ruby currently waiting for both
libtzinfo-ruby and libmemcache-client-ruby to enter the archive so that
I can upload it. One of the lines in the changelog is this:
* Now depend on the new libmemcache-client-ruby and libtzinfo-ruby packages
rather than using the embedded sources from the upstream tarball
libactivesupport-ruby ships these directories in its source:
builder-2.1.2 memcache-client-1.5.0 tzinfo-0.3.9 xml-simple-1.0.11
I thought that it would be better to have actual packages for tzinfo and
memcache-client (xml-simple and builder are already packaged for Debian)
than to continue using the ones shipped as part of the
libactivesupport-ruby package sources. My rationale was that someone
could legitimately file an RC bug against libactivesupport-ruby for
using embedded sources in that manner.
The situation initially escaped my notice and when I realized the
situation, I consulted with AthenaCR (who hired me to maintain
libactivesupport-ruby and libactiverecord-ruby, among other packages for
them) and they were in agreement. Hence I filed an ITP and packaged
libtzinfo-ruby.
All that said, should I hold off uploading libactivesupport-ruby since
it will depend on libtzinfo-ruby?
I do intend to work with upstream as suggested.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
