On 11/2/11 12:32 PM, Andrea Adami wrote: > On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang <niqingli...@insigma.com.cn > <mailto:niqingli...@insigma.com.cn>> wrote: > > I'd like the 'system level configuration' solution. > > the /etc/localtime/ link can be done when packaging rootfs (using the > system level configuration). > > On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote: > > Setting the default TZ for the image is something that should be done > in a > post > > install script for the tzdata package or something similar. > > > > Since the /etc/localtime is usually a copy/hardlink or symlink to the > timezone > > data we don't want to package it up. Instead we want to perform the > actions > > that a program running on the target system itself would use to change > the > timezone. > > > > So I think the easiest approach is to add a system level configuration > variable > > (set the default). > > > > Then use this variable to populate the configuration file that > specifies the > > system timezone... and then use the post install process to check the > contents > > of a text file. > > > > Alternatively do this via an initscript -- but for folks w/ read-only > > filesystems I'm not sure that will work. > > > > --Mark > > <cut> > > Maybe I misunderstand "system level configuration" but in the meta-oe recipe > we have > > DEFAULT_TIMEZONE ?= "Europe/London" > > Maybe UTC would be better?
To me no timezone (which is UTC) is preferable as the system designer can then set the timezone, externally to the package(s). > Note how the variable is weak thus can be overridden in local.conf. > > Secondly, why do it as post-install or at image do_rootfs stage when we have > set > the variable and are therefore able to provide sane defaults in do_install? If it's done within a do_install, then the file (/etc/timezone) itself gets placed into the package. If it's in the package, then if/when someone upgrades the package from a feed the timezone gets reset to the previous value. That's a bug IMHO. If it's done as a post-install script, then the timezone configuration can be evaluated and if one isn't set -- or there is no timezone file -- then we can set it to UTC or a similar default timezone.. (the value in the DEFAULT_TIMEZONE variable is reasonable in this approach.) > Other points before starting to write a patch: > -why is the recipe in oe-core doing chown -R root:root ${D} ? There was an issue with the way the timezone data was extracted/constructed that it was have all of the build system's uid/gid preserved in the copy to the final install directory -- so when packaging incorrect usernames and groups were fed into the process causing issues. A simple chown -R root:root ${D} ensured that all of the timezone data was owned by the root user (on the target). > -the logic around # libc is removing zoneinfo files from package > Is it only eglibc? Timezone info is updated more often then the system libc. So the zoneinfo files are handled externally of the libc. This allows for easier updates over time.. (This is my guess, as I'm not familiar with exactly what this comment refers to.) > Regards > > Andrea > > | > | > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core