On 9/1/12 12:30 PM, Andrea Adami wrote:
On Fri, Aug 31, 2012 at 9:45 AM, Khem Raj <[email protected]> wrote:
On Fri, Aug 31, 2012 at 9:01 AM, Richard Purdie
<[email protected]> 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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
