This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: P J P <pj dot pandit at yahoo dot co dot in>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 01 May 2014 11:17:58 -0700
- Subject: Re: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <1396499286 dot 85118 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <534971E4 dot 6060001 at cs dot ucla dot edu> <53497633 dot 6060804 at redhat dot com> <1397324033 dot 69177 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <5349A4B0 dot 2070206 at redhat dot com> <1397375798 dot 36419 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <1397414803 dot 70882 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <534B8A9F dot 8030806 at redhat dot com> <1397469748 dot 42212 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <1398146221 dot 72442 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <1398755742 dot 94004 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <535F74EE dot 8010002 at redhat dot com> <1398775268 dot 92264 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <535FC11B dot 3000906 at cs dot ucla dot edu> <1398801168 dot 81041 dot YahooMailNeo at web192406 dot mail dot sg3 dot yahoo dot com> <5360378D dot 1060306 at cs dot ucla dot edu> <1398872997 dot 84757 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <53614148 dot 90603 at cs dot ucla dot edu> <5361D8D1 dot 60400 at redhat dot com> <5361E805 dot 9080606 at cs dot ucla dot edu> <1398927912 dot 40372 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com>
On 05/01/2014 12:05 AM, P J P wrote:
But there is a programmatic API, namely getenv ("TZ").
It requires that TZ is defined and exported on the host.
No, getenv ("TZ") works just fine when TZ is not set. getenv ("TZ")
returns a null pointer in that case, and all you need to do is toarrange
for TZ to be similarly unset in the chrooted jail.
I also said copying files across chroot(2) jail does not work. Besides, if it worked and we decided to sync files across chroot(2) jail, we would end-up creating something analogous to python-virtualenv or docker or some such thing. Which would copy 'required' files across to the new root and update them as and when required.
I'm not quite following all this, as it seems to say at first that you
can't arrange for the tz files to be the same, but later that if you
arrange for the tz files to be the same then you'd need something like
docker. The point I was trying to make is that if you want your
applications to work the same regardless of how they set TZ, then you
must arrange for the tz files to be the same. This will be true
regardless of whether the glibc API is changed.
If you don't care whether arbitrary-TZ-setting applications work the
same, then you needn't keep all the files in sync. For example, if you
know your applications will never set TZ='America/Swift_Current' and
that no sysadmin will ever set system localtime to
America/Swift_Current, you can omit the file America/Swift_Current from
your consideration, and not bother to distribute or to update that
file. This sort of optimization is application-specific, though, and
it's not clear that the glibc API needs to be changed to support it.