[lfs-dev] tzdata2012e.tar.gz

Bruce Dubbs bruce.dubbs at gmail.com
Mon Aug 20 08:12:35 PDT 2012

Matt Burgess wrote:
> On Sun, 2012-08-19 at 18:09 -0500, Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>> On Sun, Aug 19, 2012 at 12:12:20PM -0500, Bruce Dubbs wrote:
>>>> Ken,
>>>>      You suggested separating the time zone data into a separate page.
>>>> One problem is that the tarball does not expand into a separate directory.
>>>> One place where this can cause a problem is with jhalfs.  What do you
>>>> think about repackaging the data so it expands to a directory
>>>> tzdata2012e/  and storing it on anduin?
>>>> The other option is to hack jhalfs.
>>>    Earlier, I think I said something like " I'm fixing my buildscripts" -
>>> that was caused by this.  Jhalfs is, as you know, not something I use.
>> Yes, I knew that.
>>> If it's easier to repackage tzdata, we can note why we are doing that.
>>> Most changes will be known well in advance.
>> Well it was only a matter of:
>> mkdir tzdata2012e-lfs
>> cd    tzdata2012e-lfs
>> tar -xf ../tzdata2012e.tar.gz
>> cd ..
>> tar -jcf tzdata2012e-lfs.tar.bz2 tzdata2012e-lfs
>> The file is now at
>> http://anduin.linuxfromscratch.org/sources/other/tzdata2012e-lfs.tar.bz2
>> I added the -lfs to the directory name just to prevent confusion with
>> the upstream package.
>> I think this is better than trying to use a different procedure than the
>> "unpack; cd; build" process we use in all the other packages.
> I must admit, I really don't like putting 'lfs' in the tarball name.

I didn't really like it either, but ideally the extracted directory 
should be the same name as the tarball.

> Can't we still use the same 'unpack; cd; build' process, if we add a
> note that one needs to use tar's --transform option?  The following
> works for me:
> tar xf ../tzdata2012c.tar.gz --transform 's|^|tzdata-2012c/|'

Where are you located if you are extracting  ../tzdata2012c.tar.gz?

> That would still need an 'adjustment' :-) to jhalfs but shouldn't be too
> ugly and/or onerous.

If we are going to update jhalfs, then we only need:

mkdir tzdata2012e
cd    tzdata2012e
tar -xf ../tzdata2012e.tar.gz

And a big note saying the extraction procedures are different

> Additionally, this packaging issue should be reported upstream.  I don't
> mind doing that, if no one's got around to it yet?

A change in upstream packaging would be ideal.

   -- Bruce

More information about the lfs-dev mailing list