| Submitter | Ross Burton |
|---|---|
| Date | Aug. 29, 2012, 2:24 p.m. |
| Message ID | <ba35808d6976ff17d3732ffcdb56e71f8014137c.1346250187.git.ross.burton@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/35493/ |
| State | Accepted |
| Commit | efe305c275f288e248655f3a8b266f86c9893f73 |
| Headers | show |
Comments
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.
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
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
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.
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
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
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
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.
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
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
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
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.
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. > >
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
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
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.
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.
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
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
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.
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 :/
> 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
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 >
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 >
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
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 >
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
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 >
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.....
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
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.
Patch
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} }
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(-)