On Wed, Nov 2, 2011 at 8:15 PM, Mark Hatle <mark.ha...@windriver.com> wrote:
> 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. > Sure, I overlooked that! > 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.) > > maybe "Factory" then? See post-install script example: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/timezone-data/timezone-data-2011k.ebuild > > 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.) > > Comments in meta-oe recipe would suggest that apparently only eglibc is removing zoneinfo file. # Only eglibc is removing zoneinfo files from package if [ "${LIBC}"x = "eglibc"x ] ; then cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo cp -pP "${S}/iso3166.tab" ${D}${datadir}/zoneinfo fi Being that we need the files on first boot, I'm not against providing 'Factory' settings during image do_rootfs or even in base-files. The settings of timezone and locale (and keyboard) are typically done by user on first boot, at least in graphical environments. Thanks for your comments! Regards Andrea
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
