[PATCH 0/2] tzdata fixes

[PATCH 0/2] tzdata fixes

[Ross Burton]

tzdata is missing a file to make the local timezone detection actually work in
many programs, and isn't architecture specific.

The following changes since commit 603f6c631e9454d10517599e229943f2b26d08a5:

  atom-pc: Drop glibc --with-tls option, its now the only option for glibc (2012-08-21 12:15:33 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/tz

for you to fetch changes up to ba35808d6976ff17d3732ffcdb56e71f8014137c:

  tzdata: install /etc/localtime alongside /etc/timezone (2012-08-29 15:21:48 +0100)

----------------------------------------------------------------
Ross Burton (2):
      tzdata: this package isn't architecture specific
      tzdata: install /etc/localtime alongside /etc/timezone

 meta/recipes-extended/tzdata/tzdata_2012d.bb |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Ross Burton (2):
  tzdata: this package isn't architecture specific
  tzdata: install /etc/localtime alongside /etc/timezone

 meta/recipes-extended/tzdata/tzdata_2012d.bb |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
1.7.10

[PATCH 1/2] tzdata: this package isn't architecture specific

[Ross Burton]

The data files are compiled to a binary but architecture-independent format, so
this package can be allarch.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-extended/tzdata/tzdata_2012d.bb |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/tzdata/tzdata_2012d.bb b/meta/recipes-extended/tzdata/tzdata_2012d.bb
index 605bf24..31e1266 100644
--- a/meta/recipes-extended/tzdata/tzdata_2012d.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2012d.bb
@@ -5,7 +5,9 @@ LICENSE = "PD"
 LIC_FILES_CHKSUM = "file://asia;beginline=2;endline=3;md5=06468c0e84ef4d4c97045a4a29b08234"
 DEPENDS = "tzcode-native"
 
-PR = "r0"
+PR = "r1"
+
+inherit allarch
 
 RCONFLICTS_${PN} = "timezones timezone-africa timezone-america timezone-antarctica \
              timezone-arctic timezone-asia timezone-atlantic \
-- 
1.7.10

[PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Ross Burton]

Lots of code (such a GLib) expects this to exist and link to the current
timezone data.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-extended/tzdata/tzdata_2012d.bb |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/tzdata/tzdata_2012d.bb b/meta/recipes-extended/tzdata/tzdata_2012d.bb
index 31e1266..9741101 100644
--- a/meta/recipes-extended/tzdata/tzdata_2012d.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2012d.bb
@@ -5,7 +5,7 @@ LICENSE = "PD"
 LIC_FILES_CHKSUM = "file://asia;beginline=2;endline=3;md5=06468c0e84ef4d4c97045a4a29b08234"
 DEPENDS = "tzcode-native"
 
-PR = "r1"
+PR = "r2"
 
 inherit allarch
 
@@ -49,6 +49,7 @@ do_install () {
         # Install default timezone
         install -d ${D}${sysconfdir}
         echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
+        ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ${D}${sysconfdir}/localtime
 
         chown -R root:root ${D}
 }
-- 
1.7.10

Re: [PATCH 0/2] tzdata fixes

[Koen Kooi]

Op 29 aug. 2012, om 16:24 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> tzdata is missing a file to make the local timezone detection actually work in
> many programs, and isn't architecture specific.
> 
> The following changes since commit 603f6c631e9454d10517599e229943f2b26d08a5:
> 
>  atom-pc: Drop glibc --with-tls option, its now the only option for glibc (2012-08-21 12:15:33 +0100)
> 
> are available in the git repository at:
> 
>  git://git.yoctoproject.org/poky-contrib ross/tz

Since you're posting to the oe-core list, why aren't you posting a branch that is actually mergeable into oe-core?!?!?!?

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Koen Kooi]

Op 29 aug. 2012, om 16:24 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> Lots of code (such a GLib) expects this to exist and link to the current
> timezone data.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
> meta/recipes-extended/tzdata/tzdata_2012d.bb |    3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/tzdata/tzdata_2012d.bb b/meta/recipes-extended/tzdata/tzdata_2012d.bb
> index 31e1266..9741101 100644
> --- a/meta/recipes-extended/tzdata/tzdata_2012d.bb
> +++ b/meta/recipes-extended/tzdata/tzdata_2012d.bb
> @@ -5,7 +5,7 @@ LICENSE = "PD"
> LIC_FILES_CHKSUM = "file://asia;beginline=2;endline=3;md5=06468c0e84ef4d4c97045a4a29b08234"
> DEPENDS = "tzcode-native"
> 
> -PR = "r1"
> +PR = "r2"
> 
> inherit allarch
> 
> @@ -49,6 +49,7 @@ do_install () {
>         # Install default timezone
>         install -d ${D}${sysconfdir}
>         echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
> +        ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ${D}${sysconfdir}/localtime

Awesome! I've been campaigning for the symlink solution for a while now. Good thing that split-/usr nonsense is over now.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Paul Eggleton]

On Wednesday 29 August 2012 16:47:10 Koen Kooi wrote:
> Op 29 aug. 2012, om 16:24 heeft Ross Burton <ross.burton@intel.com> het 
volgende geschreven:
> > Lots of code (such a GLib) expects this to exist and link to the current
> > timezone data.
> > 
> > Signed-off-by: Ross Burton <ross.burton@intel.com>
> > ---
> > meta/recipes-extended/tzdata/tzdata_2012d.bb |    3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-extended/tzdata/tzdata_2012d.bb
> > b/meta/recipes-extended/tzdata/tzdata_2012d.bb index 31e1266..9741101
> > 100644
> > --- a/meta/recipes-extended/tzdata/tzdata_2012d.bb
> > +++ b/meta/recipes-extended/tzdata/tzdata_2012d.bb
> > @@ -5,7 +5,7 @@ LICENSE = "PD"
> > LIC_FILES_CHKSUM =
> > "file://asia;beginline=2;endline=3;md5=06468c0e84ef4d4c97045a4a29b08234"
> > DEPENDS = "tzcode-native"
> > 
> > -PR = "r1"
> > +PR = "r2"
> > 
> > inherit allarch
> > 
> > @@ -49,6 +49,7 @@ do_install () {
> > 
> >         # Install default timezone
> >         install -d ${D}${sysconfdir}
> >         echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
> > 
> > +        ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE}
> > ${D}${sysconfdir}/localtime
>
> Awesome! I've been campaigning for the symlink solution for a while now.
> Good thing that split-/usr nonsense is over now.

How do you get that from this patch?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 15:47, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Awesome! I've been campaigning for the symlink solution for a while now. Good thing that split-/usr nonsense is over now.

Pointing out that the ln should be a cp for crazy split /usr systems
would have been sufficient, Koen.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Koen Kooi]

Op 29 aug. 2012, om 17:23 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 29 August 2012 15:47, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Awesome! I've been campaigning for the symlink solution for a while now. Good thing that split-/usr nonsense is over now.
> 
> Pointing out that the ln should be a cp for crazy split /usr systems
> would have been sufficient, Koen.

Ehm, I *really* want it to be a symlink, that way you easily check what the timezone is without needing to boot the device or compare md5sums. The last thing the TSC said on the split /usr was something along the lines of "would be nice, but only if it doesn't make things worse". A cp instead of ln would make things worse IMO.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 17:50, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Ehm, I *really* want it to be a symlink, that way you easily check what the timezone is without needing to boot the device or compare md5sums. The last thing the TSC said on the split /usr was something along the lines of "would be nice, but only if it doesn't make things worse". A cp instead of ln would make things worse IMO.

I'm all in favour of dropping the / and /usr split.  If we get a
definitive direction we can stop these arguments. :)

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Paul Eggleton]

On Wednesday 29 August 2012 17:57:16 Burton, Ross wrote:
> On 29 August 2012 17:50, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > Ehm, I *really* want it to be a symlink, that way you easily check what
> > the timezone is without needing to boot the device or compare md5sums.
> > The last thing the TSC said on the split /usr was something along the
> > lines of "would be nice, but only if it doesn't make things worse". A cp
> > instead of ln would make things worse IMO.
>
> I'm all in favour of dropping the / and /usr split.  If we get a
> definitive direction we can stop these arguments. :)

Well, the TSC as a group is still keen on supporting it last time it was 
discussed (a few meetings ago) as Koen mentions.

Surely this specific situation is pretty easy to solve for everyone using a 
postinst which is able to apply some logic - i.e. if the file is on a separate 
filesystem then cp the file, otherwise symlink it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 18:01, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> Well, the TSC as a group is still keen on supporting it last time it was
> discussed (a few meetings ago) as Koen mentions.
>
> Surely this specific situation is pretty easy to solve for everyone using a
> postinst which is able to apply some logic - i.e. if the file is on a separate
> filesystem then cp the file, otherwise symlink it.

Sounds like a lot of extra work when the choice is fairly clear.
Either we don't support split file systems and mandate initramfs for
network boots, or we do our best to support it.  With a decision on
that the choice of cp vs ln is obvious.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Phil Blundell]

On Wed, 2012-08-29 at 18:31 +0100, Burton, Ross wrote:
> Sounds like a lot of extra work when the choice is fairly clear.
> Either we don't support split file systems and mandate initramfs for
> network boots, or we do our best to support it.  With a decision on
> that the choice of cp vs ln is obvious.

Even if the TSC decides that OE-core ought still to offer the option of
split /usr, that doesn't necessarily mean that all distros will want to
take the option up.  Ideally folks who don't want/need a separate /usr
would be able to get a symlink rather than a copy.

p.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 20:12, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-08-29 at 18:31 +0100, Burton, Ross wrote:
>> Sounds like a lot of extra work when the choice is fairly clear.
>> Either we don't support split file systems and mandate initramfs for
>> network boots, or we do our best to support it.  With a decision on
>> that the choice of cp vs ln is obvious.
>
> Even if the TSC decides that OE-core ought still to offer the option of
> split /usr, that doesn't necessarily mean that all distros will want to
> take the option up.  Ideally folks who don't want/need a separate /usr
> would be able to get a symlink rather than a copy.

Sounds like they'll need to write a tool to run after every package
operation and hunt out symlinks in /etc (and other top-levels) to
files in /usr and turn those into copies.  Anything attempted on a
per-package level will fail.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Wed, Aug 29, 2012 at 12:20 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> Sounds like they'll need to write a tool to run after every package
> operation and hunt out symlinks in /etc (and other top-levels) to
> files in /usr and turn those into copies.  Anything attempted on a
> per-package level will fail.

why cant you have symlinks across /usr and / all you have to do is
ignore the warning
about cross reference. We dont want to be in a situation where
everything is ending up
in /lib and /bin and so on. I am afraid thats where we are headed as
more and more patches are coming where we are moving libraries from
/usr/lib into /lib against the wishes of package owners who want them
to be in /usr. rest of linux
world is moving in opposite direction where /usr is just fine and
considered existing along with rest of basefile structure.

see

http://lwn.net/Articles/483921/

http://lwn.net/Articles/431185/


 More and more packages are now assuming /usr
and we would have to keep fixing them to support our view of world if
we go strict
about enforcing / and /usr separation there is unionfs and initramfs
and so many other techniques to solve this problem now a days we dont
have to differentiate between / and /usr

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 22:38, Khem Raj <raj.khem@gmail.com> wrote:
> rest of linux
> world is moving in opposite direction where /usr is just fine and
> considered existing along with rest of basefile structure.

Agreed.  I'm with the side that says split / and /usr doesn't really
work and they should always be the same filesystem.

I'm curious if the people who want / and /usr on separate partitions
that Phil refers to are a hypothetical group of people, or people who
can chime in with their opinion.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Phil Blundell]

On Wed, 2012-08-29 at 22:50 +0100, Burton, Ross wrote:
> I'm curious if the people who want / and /usr on separate partitions
> that Phil refers to are a hypothetical group of people, or people who
> can chime in with their opinion.

As far as I know, only Intel have ever expressed any real interest in
having this feature work.  My recollection is that there are some
supposed "carrier grade" systems where this is, for whatever reason, a
requirement.  There's been some previous discussion on the list, see for
example:

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/017360.html 

and the follow-ups to that message.

p.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Wed, Aug 29, 2012 at 3:22 PM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-08-29 at 22:50 +0100, Burton, Ross wrote:
>> I'm curious if the people who want / and /usr on separate partitions
>> that Phil refers to are a hypothetical group of people, or people who
>> can chime in with their opinion.
>
> As far as I know, only Intel have ever expressed any real interest in
> having this feature work.  My recollection is that there are some
> supposed "carrier grade" systems where this is, for whatever reason, a
> requirement.

whatever the reasons are. Its not clear what are reasons these systems can
not use techniques available now a days for creating new systems. I can
understand if OE had a legacy of it but seemingly its a feature being added.
I see that as an exception and not norm and we are treating as norm.

 There's been some previous discussion on the list, see for
> example:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/017360.html
>
> and the follow-ups to that message.
>
> p.
>
>

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 17:50, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Ehm, I *really* want it to be a symlink, that way you easily check what the timezone is without needing to boot the device or compare md5sums. The last thing the TSC said on the split /usr was something along the lines of "would be nice, but only if it doesn't make things worse". A cp instead of ln would make things worse IMO.

Branch updated with a symlink, and the following commit message:

    tzdata: install /etc/localtime alongside /etc/timezone

    Lots of code (such a GLib) expects this to exist and link to the current
    timezone definition.

    /etc/localtime is a symlink instead of a copy of hard link to make
it obvious
    what timezone data it's pointing at. For systems with /etc on a separate
    filesystem to /usr this will result in a dangling symlink until
/usr is mounted,
    but as this is early boot the assumption is that anything checking it will
    handle that case and fallback to UTC.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 29 August 2012 23:22, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-08-29 at 22:50 +0100, Burton, Ross wrote:
>> I'm curious if the people who want / and /usr on separate partitions
>> that Phil refers to are a hypothetical group of people, or people who
>> can chime in with their opinion.
>
> As far as I know, only Intel have ever expressed any real interest in
> having this feature work.  My recollection is that there are some
> supposed "carrier grade" systems where this is, for whatever reason, a
> requirement.  There's been some previous discussion on the list, see for
> example:

The interesting mail in that thread is
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/017373.html,
where Mark Hatle from Wind River not Intel (yeah, okay...) cites
carrier grade blade systems.  Then again I've had a few years away
from OE, and I've no idea what the "micro" system referred to in later
mails is.

Considering the modern oe-core boot rapidly reaches udev and thus can
silently break in subtle way with /usr unmounted, I'm not entirely
happy with claiming to support separate partitions unless you define
support as just "gets to a shell".

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Phil Blundell]

On Thu, 2012-08-30 at 11:00 +0100, Burton, Ross wrote:
> Then again I've had a few years away
> from OE, and I've no idea what the "micro" system referred to in later
> mails is.

micro is a DISTRO which, among other things, folds /usr and / into a
single tree (i.e. $bindir == $base_bindir, etc.).  If you're using that
configuration then clearly /usr and / must, by definition, be on the
same filesystem and this is an example of a situation where we wouldn't
want to make copies.

p.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Phil Blundell]

On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
> As far as I know, only Intel have ever expressed any real interest in
> having this feature work.  My recollection is that there are some
> supposed "carrier grade" systems where this is, for whatever reason, a
> requirement. 

None of the carrier-grade people (or indeed any others) seem to have
spoken up in favour of a separate /usr in the past 3 days or so, which
does rather suggest that nobody actually cares about it.  

Maybe the TSC would like to reconsider whether this is in fact a
worthwhile thing to go on trying to support in oe-core or whether it
should just assume that / and ${prefix} will be the same filesystem.

p.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Fri, Aug 31, 2012 at 7:29 AM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
>> As far as I know, only Intel have ever expressed any real interest in
>> having this feature work.  My recollection is that there are some
>> supposed "carrier grade" systems where this is, for whatever reason, a
>> requirement.
>
> None of the carrier-grade people (or indeed any others) seem to have
> spoken up in favour of a separate /usr in the past 3 days or so, which
> does rather suggest that nobody actually cares about it.
>
> Maybe the TSC would like to reconsider whether this is in fact a
> worthwhile thing to go on trying to support in oe-core or whether it
> should just assume that / and ${prefix} will be the same filesystem.
>


yes it will be brought forth
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Richard Purdie]

On Fri, 2012-08-31 at 15:29 +0100, Phil Blundell wrote:
> On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
> > As far as I know, only Intel have ever expressed any real interest in
> > having this feature work.  My recollection is that there are some
> > supposed "carrier grade" systems where this is, for whatever reason, a
> > requirement. 
> 
> None of the carrier-grade people (or indeed any others) seem to have
> spoken up in favour of a separate /usr in the past 3 days or so, which
> does rather suggest that nobody actually cares about it.  
> 
> Maybe the TSC would like to reconsider whether this is in fact a
> worthwhile thing to go on trying to support in oe-core or whether it
> should just assume that / and ${prefix} will be the same filesystem.

I think the people in question are at a conference at the moment and
dealing with a few issues so they fact they haven't spoken up doesn't
surprise me.

I'm fine with merging the symlink change. As others have mentioned, if
it is an issue, a script to turn the links into copies can be written
relatively easily.

I don't think dropping support for / and ${prefix} makes sense as long
as it doesn't excessively hurt us. It is up to users to step up and help
maintain the use cases they care about and so far, they have done this.
So I think the position the TSC took is the correct one. Certainly we
can revisit it but its not going to stop this patch going in for
example.

Cheers,

Richard

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Fri, Aug 31, 2012 at 9:01 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> I don't think dropping support for / and ${prefix} makes sense as long
> as it doesn't excessively hurt us

we already have, done special things to support it look how many
libraries appear in /lib now a days despite their original build
system wanting it in /usr and I still get atleast 50 warnings on it
wanting more in /lib and I am sure someone will send patches
for it because they hate the warning and then we will have this
growing pile of patches
to maintain. So IMO it has already started to hurt us.

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Fri, Aug 31, 2012 at 9:45 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Aug 31, 2012 at 9:01 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>
>> I don't think dropping support for / and ${prefix} makes sense as long
>> as it doesn't excessively hurt us
>
> we already have, done special things to support it look how many
> libraries appear in /lib now a days despite their original build
> system wanting it in /usr and I still get atleast 50 warnings on it
> wanting more in /lib and I am sure someone will send patches
> for it because they hate the warning and then we will have this
> growing pile of patches
> to maintain. So IMO it has already started to hurt us.

just to quantify it. I have 11 warnings reported about it.

WARNING: QA Issue: .... installed in the base_prefix, requires a
shared library under exec_prefix (/usr)

this is very custom image but very much similar to core-image-minimal
now if I fix this 11 warnings. For the sake of it I fixed these 11 warnings
by hacking patches for packages or recipes to move these files into
base_prefix and it now gives me 16 more warnings about same but
different files it wants to bring along into base_prefix

its quite slimy :/

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Andrea Adami]

> On Fri, Aug 31, 2012 at 9:45 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Fri, Aug 31, 2012 at 9:01 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> 
>>> I don't think dropping support for / and ${prefix} makes sense as long
>>> as it doesn't excessively hurt us
>> 
>> we already have, done special things to support it look how many
>> libraries appear in /lib now a days despite their original build
>> system wanting it in /usr and I still get atleast 50 warnings on it
>> wanting more in /lib and I am sure someone will send patches
>> for it because they hate the warning and then we will have this
>> growing pile of patches
>> to maintain. So IMO it has already started to hurt us.
> 
> just to quantify it. I have 11 warnings reported about it.
> 
> WARNING: QA Issue: .... installed in the base_prefix, requires a
> shared library under exec_prefix (/usr)
> 
> this is very custom image but very much similar to core-image-minimal
> now if I fix this 11 warnings. For the sake of it I fixed these 11 warnings
> by hacking patches for packages or recipes to move these files into
> base_prefix and it now gives me 16 more warnings about same but
> different files it wants to bring along into base_prefix
> 
> its quite slimy :/

As Khem says, leading distros are even going one step further:

http:\\fedoraproject.org/wiki/Features/UsrMove

Seems it's time to consider alternative rootfs layouts, like this F17 unified filesystem.

Andrea

> __________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Mark Hatle]

On 8/31/12 11:01 AM, Richard Purdie wrote:
> On Fri, 2012-08-31 at 15:29 +0100, Phil Blundell wrote:
>> On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
>>> As far as I know, only Intel have ever expressed any real interest in
>>> having this feature work.  My recollection is that there are some
>>> supposed "carrier grade" systems where this is, for whatever reason, a
>>> requirement.
>>
>> None of the carrier-grade people (or indeed any others) seem to have
>> spoken up in favour of a separate /usr in the past 3 days or so, which
>> does rather suggest that nobody actually cares about it.
>>
>> Maybe the TSC would like to reconsider whether this is in fact a
>> worthwhile thing to go on trying to support in oe-core or whether it
>> should just assume that / and ${prefix} will be the same filesystem.
>
> I think the people in question are at a conference at the moment and
> dealing with a few issues so they fact they haven't spoken up doesn't
> surprise me.

As Richard mentioned, a lot of folks were at a conference last week and with the 
holiday (in the US) over the weekend were not around to reply before.

> I'm fine with merging the symlink change. As others have mentioned, if
> it is an issue, a script to turn the links into copies can be written
> relatively easily.

Frankly, I'm an advocate of the split, and I'm in favor of the symlink change. 
A dangling link is fine for a non-criticial component like a timezone file.  If 
the system attempts to get the time, it will simply fall back to GMT, which to 
me is acceptable on embedded systems.

> I don't think dropping support for / and ${prefix} makes sense as long
> as it doesn't excessively hurt us. It is up to users to step up and help
> maintain the use cases they care about and so far, they have done this.
> So I think the position the TSC took is the correct one. Certainly we
> can revisit it but its not going to stop this patch going in for
> example.

Again, I agree with this.

At Wind River we've been following up and sending patches.  The issue is that we 
(OE) need to keep reviewing them and determining if they continue to make sense 
or not.  If we get into a situation where we've moved everything from /usr to /, 
it's pretty clear it no longer makes sense!  However, we're still far from the 
point.

initramdisk (from the comments to the links Khem sent out) is certainly a 
primary issue, but not the one I've been focused on in the past...

A number of devices that I've worked with do something -similar- to the ramdisk 
for early booting.  Boot order becomes:

firmware/bootloader -> kernel -> [small] rootfs mount (RO) -> run init

init -> module loading -> setup -> 'late' udev config -> mount filesystems 
(/usr) -> 'early' udev config

(late udev is running the daemon and watching for hotplug events, early udev is 
what triggers device creation behaviors.  The orders are switched both for 
performance, and because other then plugable devices -- the device tree is more 
or less static from one boot to the next, so our root has it pre-seeded...)

Many of the devices also have a validation and restoration system on root as 
well, that is performed by the setup step.  If the validation fails, then 
corrective actions can be taken to "fix" the system.  The / is always a RO 
system.. the device may contain more then one '/' to allow for upgrades, but the 
active one is always RO to avoid various potential problems.

The more software that gets put onto the system, the harder it will be to do 
field upgrades w/o a reboot.  (Since we don't want to allow / to change.)

Keeping the root small makes for a quicker boot, smaller set of partitions, and 
easier restoration on failure in my experience.

---

Again, if creating split systems no longer makes sense, I'm not against dumping 
the code..  I am going to be monitoring our customers, as much as I'm able, over 
the next 6 months -> year and seeing if anyone is doing this type of split 
anymore.. if they're not.. then we (OE) may, justifiably, abandon this behavior.

--Mark

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Mark Hatle]

On 9/1/12 12:30 PM, Andrea Adami wrote:
>
>> On Fri, Aug 31, 2012 at 9:45 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Fri, Aug 31, 2012 at 9:01 AM, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>
>>>> I don't think dropping support for / and ${prefix} makes sense as long
>>>> as it doesn't excessively hurt us
>>>
>>> we already have, done special things to support it look how many
>>> libraries appear in /lib now a days despite their original build
>>> system wanting it in /usr and I still get atleast 50 warnings on it
>>> wanting more in /lib and I am sure someone will send patches
>>> for it because they hate the warning and then we will have this
>>> growing pile of patches
>>> to maintain. So IMO it has already started to hurt us.
>>
>> just to quantify it. I have 11 warnings reported about it.
>>
>> WARNING: QA Issue: .... installed in the base_prefix, requires a
>> shared library under exec_prefix (/usr)
>>
>> this is very custom image but very much similar to core-image-minimal
>> now if I fix this 11 warnings. For the sake of it I fixed these 11 warnings
>> by hacking patches for packages or recipes to move these files into
>> base_prefix and it now gives me 16 more warnings about same but
>> different files it wants to bring along into base_prefix
>>
>> its quite slimy :/
>
> As Khem says, leading distros are even going one step further:
>
> http:\\fedoraproject.org/wiki/Features/UsrMove
>
> Seems it's time to consider alternative rootfs layouts, like this F17 unified filesystem.

I really dislike their snarky FAQ..

I'm sorry, not all devices being generated have initramfs configuration (nor do 
people want that behavior.)   Also we've shown you can build a system w/ a split 
filesystem and it works properly.  The systemd/udev developers seem 'lazy' to 
me... they were unwilling to work through early and late boot so they just gave up.

The comments in the FAQ about /etc and /var being local to a given machine, 
while /usr being shareable is a reasonable set.  This is the situations where 
I've seen this used the most especially in blade systems w/ a local rootfs on 
each, with a shared /usr among them all.

I agree it can make some update processes more difficult, but the reality is 
there are already mechanisms in place -- for many products -- that address this.

Perhaps one way around the whole argument is simply to redefine the problem. 
(As Fedora and others seem to have done.)  Work on an OE solution to construct a 
minimal boot/configuration system that can load the appropriate (combined) /usr 
partition, and then pivot-root, or similar and re-exec init to switch to that 
configuration?  This is similar in concept to the initramfs, but is not tied to 
a specific technique or technology.

This would still allow for the quick boot configuration (RO mount even), udev 
setup, module loading and such -- and the larger /usr partition and upgrade path.

This is not something we have in OE today, and would certainly require some 
custom work.....

--Mark

> 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
>

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 4 September 2012 17:28, Mark Hatle <mark.hatle@windriver.com> wrote:
> I'm sorry, not all devices being generated have initramfs configuration (nor
> do people want that behavior.)   Also we've shown you can build a system w/
> a split filesystem and it works properly.  The systemd/udev developers seem
> 'lazy' to me... they were unwilling to work through early and late boot so
> they just gave up.

With oe-core master, I get:

NOTE: Executing RunQueue Tasks
WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the
base_prefix, requires a shared library under exec_prefix (/usr):
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xdead2000)

So that's a false positive, and libgudev can be moved back into /usr
where it belongs?

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Mark Hatle]

On 9/4/12 2:26 PM, Burton, Ross wrote:
> On 4 September 2012 17:28, Mark Hatle <mark.hatle@windriver.com> wrote:
>> I'm sorry, not all devices being generated have initramfs configuration (nor
>> do people want that behavior.)   Also we've shown you can build a system w/
>> a split filesystem and it works properly.  The systemd/udev developers seem
>> 'lazy' to me... they were unwilling to work through early and late boot so
>> they just gave up.
>
> With oe-core master, I get:
>
> NOTE: Executing RunQueue Tasks
> WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the
> base_prefix, requires a shared library under exec_prefix (/usr):
> libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xdead2000)
>
> So that's a false positive, and libgudev can be moved back into /usr
> where it belongs?

The gobject linkage into udev is either the result of a newer version of udev, 
different configuration options or "something else".  The version we're using 
from the Denzil branch did not generate this failure.  (maybe the check was in 
error?)

This type of problem is the "peeling of the onion" problem.  You fix one, and 
you expose the next problem.  Each of these are really problems..  the catch is 
at the end of the process do you eliminate the problem (in a sustainable way) or 
not.  For this particular issue, I haven't looked at udev in a while to see 
where the dependency is coming from, and why it is there..

--Mark

> Ross
>

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Burton, Ross]

On 4 September 2012 20:44, Mark Hatle <mark.hatle@windriver.com> wrote:
>> So that's a false positive, and libgudev can be moved back into /usr
>> where it belongs?
>
> The gobject linkage into udev is either the result of a newer version of
> udev, different configuration options or "something else".  The version
> we're using from the Denzil branch did not generate this failure.  (maybe
> the check was in error?)

gudev is relatively new, so probably isn't in the Denzil udev.  It
would be interesting to see if it's used in early boot or not (I
suspect not, as it depends on GObject), and only selectively move
parts of udev to /lib as required instead of forcing everything to
move.

Ross

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Mark Hatle]

On 9/4/12 3:06 PM, Burton, Ross wrote:
> On 4 September 2012 20:44, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> So that's a false positive, and libgudev can be moved back into /usr
>>> where it belongs?
>>
>> The gobject linkage into udev is either the result of a newer version of
>> udev, different configuration options or "something else".  The version
>> we're using from the Denzil branch did not generate this failure.  (maybe
>> the check was in error?)
>
> gudev is relatively new, so probably isn't in the Denzil udev.  It
> would be interesting to see if it's used in early boot or not (I
> suspect not, as it depends on GObject), and only selectively move
> parts of udev to /lib as required instead of forcing everything to
> move.

Ya, understanding how it's used and when.. it should be much easier to make a 
good choice.  I know in the past I've been able to break apart things like this.

--Mark

> Ross
>

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Tue, Sep 4, 2012 at 9:28 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>
> I'm sorry, not all devices being generated have initramfs configuration (nor
> do people want that behavior.)   Also we've shown you can build a system w/
> a split filesystem and it works properly.

yes if every package followed this sadly thats a more and more
diverging case now a days.
so do we diverge and it there a compelling case to do so. I would do
it if 80% of our usecase was this one
but this seems like a one off thing so either we find a better
solution or we abandon it. In my opinion
such a thing should be a configure option disabled by default and
whoever has the usecase for it
can enable it but not default

there is a use case where now people are asking can I use this fedora
prebuilt rpm with yocto/OE
and so on and if we diverge too much on root file system layout by
default we can get sidelined.

  The systemd/udev developers seem
> 'lazy' to me... they were unwilling to work through early and late boot so
> they just gave up.

Linux was never supposed to have / and /usr different to begin with

>
> The comments in the FAQ about /etc and /var being local to a given machine,
> while /usr being shareable is a reasonable set.  This is the situations
> where I've seen this used the most especially in blade systems w/ a local
> rootfs on each, with a shared /usr among them all.
>
> I agree it can make some update processes more difficult, but the reality is
> there are already mechanisms in place -- for many products -- that address
> this.
>
> Perhaps one way around the whole argument is simply to redefine the problem.
> (As Fedora and others seem to have done.)  Work on an OE solution to
> construct a minimal boot/configuration system that can load the appropriate
> (combined) /usr partition, and then pivot-root, or similar and re-exec init
> to switch to that configuration?  This is similar in concept to the
> initramfs, but is not tied to a specific technique or technology.
>
> This would still allow for the quick boot configuration (RO mount even),
> udev setup, module loading and such -- and the larger /usr partition and
> upgrade path.


>
> This is not something we have in OE today, and would certainly require some
> custom work.....

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Paul Eggleton]

On Tuesday 04 September 2012 14:29:08 Khem Raj wrote:
> Linux was never supposed to have / and /usr different to begin with

So I agree this is hard to do properly now and is going to be impossible to 
keep up with as time goes on, but where do you get this from?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Khem Raj]

On Thu, Sep 6, 2012 at 2:32 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> So I agree this is hard to do properly now and is going to be impossible to
> keep up with as time goes on, but where do you get this from?

read the links I posted in this thread earlier.