* libs transition /usr/lib -> /lib questions
@ 2012-01-05 23:29 Andreas Müller
2012-01-06 3:35 ` Scott Garman
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Andreas Müller @ 2012-01-05 23:29 UTC (permalink / raw)
To: openembedded-core
Hi
currently some libs are moving from $libdir (/usr/lib) -> $base_libdir (/lib). I
have the following questions:
* can sombody explain a bit more what is it for and how the decision is made to
transit libs? I read the commit messages but still have no idea what this
enhances / fixes. What is 'not safe' or - I guess the insane.bbclass modification
deals same issue - 'system recovery'. Is that something I (should) have? :)
* can somebody please take care what I see with meta-oe / obexd:
| ./arm-angstrom-linux-gnueabi-libtool --tag=CC --mode=link ccache arm-
angstrom-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-
interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-
thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -
I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/glib-2.0 -
I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/glib-2.0/include -
I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/dbus-1.0 -
I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/dbus-1.0/include -
D_FILE_OFFSET_BITS=64 -DOBEX_PLUGIN_BUILTIN -
DPLUGINDIR=\""/usr/lib/obex/plugins"\" -O -fno-omit-frame-pointer -g -
feliminate-unused-debug-types -pipe -O0 -Wl,--export-dynamic -Wl,-O1 -Wl,--hash-
style=gnu -Wl,--as-needed -o src/obexd gdbus/mainloop.o gdbus/watch.o
gdbus/object.o gdbus/polkit.o plugins/bluetooth.o plugins/filesystem.o
plugins/opp.o plugins/ftp.o plugins/pbap.o plugins/vcard.o plugins/mas.o
plugins/irmc.o plugins/syncevolution.o btio/btio.o src/main.o src/plugin.o
src/log.o src/manager.o src/obex.o src/mimetype.o src/service.o src/transport.o
src/server.o plugins/phonebook.o plugins/messages.o -ldbus-1 -lpthread -lrt -
lglib-2.0 -lopenobex -lbluetooth -lical -licalss -licalvcal -lpthread -ldl
| arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
`/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
unhandled argument `=/lib/libusb-1.0.la'
| make[1]: *** [src/obexd] Error 1
libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
transition too? If yes: Are there also others which need libtool-lib transition?
Thanks
Andreas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-05 23:29 libs transition /usr/lib -> /lib questions Andreas Müller
@ 2012-01-06 3:35 ` Scott Garman
2012-01-06 13:33 ` Andreas Müller
2012-01-06 10:48 ` Enrico Scholz
2012-01-06 15:48 ` Mark Hatle
2 siblings, 1 reply; 14+ messages in thread
From: Scott Garman @ 2012-01-06 3:35 UTC (permalink / raw)
To: openembedded-core
On 01/05/2012 03:29 PM, Andreas Müller wrote:
> Hi
>
> currently some libs are moving from $libdir (/usr/lib) -> $base_libdir (/lib). I
> have the following questions:
>
> * can sombody explain a bit more what is it for and how the decision is made to
> transit libs? I read the commit messages but still have no idea what this
> enhances / fixes. What is 'not safe' or - I guess the insane.bbclass modification
> deals same issue - 'system recovery'. Is that something I (should) have? :)
> * can somebody please take care what I see with meta-oe / obexd:
>
> | ./arm-angstrom-linux-gnueabi-libtool --tag=CC --mode=link ccache arm-
> angstrom-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-
> interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-
> thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/glib-2.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/glib-2.0/include -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/dbus-1.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/dbus-1.0/include -
> D_FILE_OFFSET_BITS=64 -DOBEX_PLUGIN_BUILTIN -
> DPLUGINDIR=\""/usr/lib/obex/plugins"\" -O -fno-omit-frame-pointer -g -
> feliminate-unused-debug-types -pipe -O0 -Wl,--export-dynamic -Wl,-O1 -Wl,--hash-
> style=gnu -Wl,--as-needed -o src/obexd gdbus/mainloop.o gdbus/watch.o
> gdbus/object.o gdbus/polkit.o plugins/bluetooth.o plugins/filesystem.o
> plugins/opp.o plugins/ftp.o plugins/pbap.o plugins/vcard.o plugins/mas.o
> plugins/irmc.o plugins/syncevolution.o btio/btio.o src/main.o src/plugin.o
> src/log.o src/manager.o src/obex.o src/mimetype.o src/service.o src/transport.o
> src/server.o plugins/phonebook.o plugins/messages.o -ldbus-1 -lpthread -lrt -
> lglib-2.0 -lopenobex -lbluetooth -lical -licalss -licalvcal -lpthread -ldl
> | arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
> `/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
> unhandled argument `=/lib/libusb-1.0.la'
> | make[1]: *** [src/obexd] Error 1
>
> libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
> transition too? If yes: Are there also others which need libtool-lib transition?
>
> Thanks
>
> Andreas
Hi Andreas,
I think you mentioned in another thread that the "why" part of your
question has been addressed. As for the location of libusb-1.0.la - it
looks like Richard previously missed one of my commits moving
libusb-compat, and just merged it to oe-core master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=198f2ac06e60245750a2c6561b8c8e2eaa93f6be
Does this fix the issue?
I may be hard to reach tomorrow, so I hope RP or Mark Hatle can field
any further questions for me.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-05 23:29 libs transition /usr/lib -> /lib questions Andreas Müller
2012-01-06 3:35 ` Scott Garman
@ 2012-01-06 10:48 ` Enrico Scholz
2012-01-06 15:48 ` Mark Hatle
2 siblings, 0 replies; 14+ messages in thread
From: Enrico Scholz @ 2012-01-06 10:48 UTC (permalink / raw)
To: openembedded-core
Andreas Müller <schnitzeltony-Mmb7MZpHnFY@public.gmane.org> writes:
> currently some libs are moving from $libdir (/usr/lib) -> $base_libdir
> (/lib).
Parts of these changes are wrong resp. require adaptations in the build
system. Devel .so files can stay in /usr/lib; moving them to /lib breaks
builds because /lib is not in the 'ld' search path.
Enrico
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 3:35 ` Scott Garman
@ 2012-01-06 13:33 ` Andreas Müller
0 siblings, 0 replies; 14+ messages in thread
From: Andreas Müller @ 2012-01-06 13:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Friday, January 06, 2012 04:35:11 AM Scott Garman wrote:
> On 01/05/2012 03:29 PM, Andreas Müller wrote:
> > Hi
> >
> > currently some libs are moving from $libdir (/usr/lib) -> $base_libdir
> > (/lib). I have the following questions:
> >
> > * can sombody explain a bit more what is it for and how the decision is
> > made to transit libs? I read the commit messages but still have no idea
> > what this enhances / fixes. What is 'not safe' or - I guess the
> > insane.bbclass modification deals same issue - 'system recovery'. Is
> > that something I (should) have? :)
> >
> > * can somebody please take care what I see with meta-oe / obexd:
> >
> > | arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
> >
> > `/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
> > unhandled argument `=/lib/libusb-1.0.la'
> >
> > | make[1]: *** [src/obexd] Error 1
> >
> > libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
> > transition too? If yes: Are there also others which need libtool-lib
> > transition?
> >
> > Thanks
> >
> > Andreas
>
> Hi Andreas,
>
> I think you mentioned in another thread that the "why" part of your
> question has been addressed.
Yes.
> As for the location of libusb-1.0.la - it
> looks like Richard previously missed one of my commits moving
> libusb-compat, and just merged it to oe-core master:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=198f2ac06e6024575
> 0a2c6561b8c8e2eaa93f6be
>
> Does this fix the issue?
>
> I may be hard to reach tomorrow, so I hope RP or Mark Hatle can field
> any further questions for me.
>
I think the problem I reported was that *.la is in /usr/lib while all others are
now in /lib. I tried moving libusb-1.0.la to /lib manually and rebuild udev and
obexd without issues.
So why are your patches moving *.la back to /usr/lib?
Andreas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-05 23:29 libs transition /usr/lib -> /lib questions Andreas Müller
2012-01-06 3:35 ` Scott Garman
2012-01-06 10:48 ` Enrico Scholz
@ 2012-01-06 15:48 ` Mark Hatle
2012-01-22 0:05 ` Khem Raj
2 siblings, 1 reply; 14+ messages in thread
From: Mark Hatle @ 2012-01-06 15:48 UTC (permalink / raw)
To: openembedded-core
On 1/5/12 5:29 PM, Andreas Müller wrote:
> Hi
>
> currently some libs are moving from $libdir (/usr/lib) -> $base_libdir (/lib). I
> have the following questions:
>
> * can sombody explain a bit more what is it for and how the decision is made to
> transit libs? I read the commit messages but still have no idea what this
> enhances / fixes. What is 'not safe' or - I guess the insane.bbclass modification
> deals same issue - 'system recovery'. Is that something I (should) have? :)
The issue is based on the separation of the "root" (/) and "user" (/usr)
partition. It is reasonable, and in many cases advisable to breakup the system
into multiple partitions. The FHS (and UNIX tradition) support the idea of a
small root filesystem w/ a /usr partition adding the majority of the
functionality to the system. (Note: in OE-Core the 'user' partition is
equivalent to the exec_prefix, which some distributions make '/' in order to
flatten the filesystem. In this case the code will detect root and user are the
same and do nothing.)
The problem being identified, and resolved is that if a binary exists in the
root partition, then all of it's support libraries must also exist in the root
partition. I.e. "/bin/grep" can't refer to "/usr/lib/libncurses.so". Because
during early boot a script may use grep for functionality, but if /usr is not
yet mounted it will fail. Detecting this is fairly simple -- correlate the
libraries required by an executable in the root partition and verify they are
not requiring anything located in the /usr partition.
Similarly if shell scripts require functionality that only exist in /usr, then
they may also cause a failure condition if /usr is not yet mounted. (This of
course is much harder to detect, which is why this test is only a warning and
likely to only ever be a warning as there will potentially be a lot of false
positives.)
When a QA situation is detected there are three common solutions to the problem:
*) Move the required library from the user partition to root
*) Move the binary from the root partition to the user partition
*) Change the options of the binary to no longer require the library in the user
partition
Each of the above should be evaluated based on the implicit goal that the root
partition continue to be "small", with the rule of thumb that it needs to
contain enough to do early boot and mount of the user filesystem -- and
potentially recovery activities in case of a failure.
(I see Scott answered the question below already..)
--Mark
> * can somebody please take care what I see with meta-oe / obexd:
>
> | ./arm-angstrom-linux-gnueabi-libtool --tag=CC --mode=link ccache arm-
> angstrom-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-
> interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-
> thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/glib-2.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/glib-2.0/include -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/dbus-1.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/dbus-1.0/include -
> D_FILE_OFFSET_BITS=64 -DOBEX_PLUGIN_BUILTIN -
> DPLUGINDIR=\""/usr/lib/obex/plugins"\" -O -fno-omit-frame-pointer -g -
> feliminate-unused-debug-types -pipe -O0 -Wl,--export-dynamic -Wl,-O1 -Wl,--hash-
> style=gnu -Wl,--as-needed -o src/obexd gdbus/mainloop.o gdbus/watch.o
> gdbus/object.o gdbus/polkit.o plugins/bluetooth.o plugins/filesystem.o
> plugins/opp.o plugins/ftp.o plugins/pbap.o plugins/vcard.o plugins/mas.o
> plugins/irmc.o plugins/syncevolution.o btio/btio.o src/main.o src/plugin.o
> src/log.o src/manager.o src/obex.o src/mimetype.o src/service.o src/transport.o
> src/server.o plugins/phonebook.o plugins/messages.o -ldbus-1 -lpthread -lrt -
> lglib-2.0 -lopenobex -lbluetooth -lical -licalss -licalvcal -lpthread -ldl
> | arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
> `/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
> unhandled argument `=/lib/libusb-1.0.la'
> | make[1]: *** [src/obexd] Error 1
>
> libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
> transition too? If yes: Are there also others which need libtool-lib transition?
>
> Thanks
>
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 15:48 ` Mark Hatle
@ 2012-01-22 0:05 ` Khem Raj
0 siblings, 0 replies; 14+ messages in thread
From: Khem Raj @ 2012-01-22 0:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On (06/01/12 09:48), Mark Hatle wrote:
> On 1/5/12 5:29 PM, Andreas Müller wrote:
> >Hi
> >
> >currently some libs are moving from $libdir (/usr/lib) -> $base_libdir (/lib). I
> >have the following questions:
> >
> >* can sombody explain a bit more what is it for and how the decision is made to
> >transit libs? I read the commit messages but still have no idea what this
> >enhances / fixes. What is 'not safe' or - I guess the insane.bbclass modification
> >deals same issue - 'system recovery'. Is that something I (should) have? :)
>
> The issue is based on the separation of the "root" (/) and "user"
> (/usr) partition. It is reasonable, and in many cases advisable to
> breakup the system into multiple partitions. The FHS (and UNIX
> tradition) support the idea of a small root filesystem w/ a /usr
> partition adding the majority of the functionality to the system.
> (Note: in OE-Core the 'user' partition is equivalent to the
> exec_prefix, which some distributions make '/' in order to flatten
> the filesystem. In this case the code will detect root and user are
> the same and do nothing.)
>
> The problem being identified, and resolved is that if a binary
> exists in the root partition, then all of it's support libraries
> must also exist in the root partition. I.e. "/bin/grep" can't refer
> to "/usr/lib/libncurses.so". Because during early boot a script may
> use grep for functionality, but if /usr is not yet mounted it will
> fail. Detecting this is fairly simple -- correlate the libraries
> required by an executable in the root partition and verify they are
> not requiring anything located in the /usr partition.
>
> Similarly if shell scripts require functionality that only exist in
> /usr, then they may also cause a failure condition if /usr is not
> yet mounted. (This of course is much harder to detect, which is why
> this test is only a warning and likely to only ever be a warning as
> there will potentially be a lot of false positives.)
>
> When a QA situation is detected there are three common solutions to the problem:
>
> *) Move the required library from the user partition to root
>
> *) Move the binary from the root partition to the user partition
>
> *) Change the options of the binary to no longer require the library
> in the user partition
>
> Each of the above should be evaluated based on the implicit goal
> that the root partition continue to be "small", with the rule of
> thumb that it needs to contain enough to do early boot and mount of
> the user filesystem -- and potentially recovery activities in case
> of a failure.
>
> (I see Scott answered the question below already..)
>
from OE point of view its good to support as many options as possible
and the idea is ok however I think not all packages are written in a way
that the installs can be made easility relocatable. If you change a
package to make it more nicely relocatable then please write patches
that can be submitted upstream to respective packages instead of having
tweaks in the metadata. My concern is that we will have so many of these
changes in metadata as kludges to build such packages.
> --Mark
>
> >* can somebody please take care what I see with meta-oe / obexd:
> >
> >| ./arm-angstrom-linux-gnueabi-libtool --tag=CC --mode=link ccache arm-
> >angstrom-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-
> >interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-
> >thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -
> >I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/glib-2.0 -
> >I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/glib-2.0/include -
> >I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/dbus-1.0 -
> >I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/dbus-1.0/include -
> >D_FILE_OFFSET_BITS=64 -DOBEX_PLUGIN_BUILTIN -
> >DPLUGINDIR=\""/usr/lib/obex/plugins"\" -O -fno-omit-frame-pointer -g -
> >feliminate-unused-debug-types -pipe -O0 -Wl,--export-dynamic -Wl,-O1 -Wl,--hash-
> >style=gnu -Wl,--as-needed -o src/obexd gdbus/mainloop.o gdbus/watch.o
> >gdbus/object.o gdbus/polkit.o plugins/bluetooth.o plugins/filesystem.o
> >plugins/opp.o plugins/ftp.o plugins/pbap.o plugins/vcard.o plugins/mas.o
> >plugins/irmc.o plugins/syncevolution.o btio/btio.o src/main.o src/plugin.o
> >src/log.o src/manager.o src/obex.o src/mimetype.o src/service.o src/transport.o
> >src/server.o plugins/phonebook.o plugins/messages.o -ldbus-1 -lpthread -lrt -
> >lglib-2.0 -lopenobex -lbluetooth -lical -licalss -licalvcal -lpthread -ldl
> >| arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
> >`/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
> >unhandled argument `=/lib/libusb-1.0.la'
> >| make[1]: *** [src/obexd] Error 1
> >
> >libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
> >transition too? If yes: Are there also others which need libtool-lib transition?
> >
> >Thanks
> >
> >Andreas
> >
> >_______________________________________________
> >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
--
-Khem
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 16:43 ` Koen Kooi
@ 2012-01-06 16:51 ` Mark Hatle
0 siblings, 0 replies; 14+ messages in thread
From: Mark Hatle @ 2012-01-06 16:51 UTC (permalink / raw)
To: openembedded-core
On 1/6/12 10:43 AM, Koen Kooi wrote:
>
> Op 6 jan. 2012, om 17:16 heeft Richard Purdie het volgende geschreven:
>
>> On Fri, 2012-01-06 at 09:04 -0700, Chris Larson wrote:
>>> On Fri, Jan 6, 2012 at 8:59 AM, Mark Hatle<mark.hatle@windriver.com> wrote:
>>>> On 1/6/12 4:34 AM, Koen Kooi wrote:
>>>>>
>>>>>
>>>>> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
>>>>>
>>>>>> FWIW today I've noticed that systemd is going other way around
>>>>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>>>
>>>>>
>>>>> And http://fedoraproject.org/wiki/Features/UsrMove
>>>>>
>>>>> I guess it's time to publish my angstrom branch doing that after the
>>>>> holidays :)
>>>>
>>>>
>>>> I respectfully disagree with both of the above URLs.
>>>>
>>>> The root partition is still very useful as a "small" set of applications and
>>>> libraries required for booting.
>>>>
>>>> Most systems these days contain a combined root and usr partition, which is
>>>> fine. However, there are a lot of systems that I've worked on in the past
>>>> and I expect in the future that, root being a small R/O system is necessary.
>>>>
>>>> initramfs can solve some problems, but introduces other issues. Many of the
>>>> systems I've worked on simple don't have enough flash to be able to store
>>>> the bootloader, kernel and an initramfs [as well as other system items
>>>> required by the devices]. In this case a base rootfs makes the most sense.
>>>
>>> In my opinion, what's proposed in the two links is a good thing even
>>> for embedded. Not that we'd use that structure necessarily, but
>>> removing the usr vs non-usr separation for binaries and libs is a good
>>> thing regardless. Putting /usr in the rootfs still would still work
>>> fine, or you could drop usr entirely and move everything to / the way
>>> micro does.
>>
>> The nice thing is we have a system which can actually support the
>> different options relatively easily and without much conflict.
>
> Except that things like fs-perms.txt store hardcoded values :(
Yes "hard coded values" that include expandable variables:
# Documentation should always be corrected
${mandir} 0755 root root true 0644 root root
${infodir} 0755 root root true 0644 root root
${docdir} 0755 root root true 0644 root root
etc..
The format of this file was specifically setup to allow for people to adjust the
value of the exec_prefix, libdir, etc as necessary without having to change the
default fs-perms.txt. (Also keep in mind the expectation for distributions to
add their own locations when necessary.)
--Mark
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 16:16 ` Richard Purdie
@ 2012-01-06 16:43 ` Koen Kooi
2012-01-06 16:51 ` Mark Hatle
0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2012-01-06 16:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 6 jan. 2012, om 17:16 heeft Richard Purdie het volgende geschreven:
> On Fri, 2012-01-06 at 09:04 -0700, Chris Larson wrote:
>> On Fri, Jan 6, 2012 at 8:59 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 1/6/12 4:34 AM, Koen Kooi wrote:
>>>>
>>>>
>>>> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
>>>>
>>>>> FWIW today I've noticed that systemd is going other way around
>>>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>>
>>>>
>>>> And http://fedoraproject.org/wiki/Features/UsrMove
>>>>
>>>> I guess it's time to publish my angstrom branch doing that after the
>>>> holidays :)
>>>
>>>
>>> I respectfully disagree with both of the above URLs.
>>>
>>> The root partition is still very useful as a "small" set of applications and
>>> libraries required for booting.
>>>
>>> Most systems these days contain a combined root and usr partition, which is
>>> fine. However, there are a lot of systems that I've worked on in the past
>>> and I expect in the future that, root being a small R/O system is necessary.
>>>
>>> initramfs can solve some problems, but introduces other issues. Many of the
>>> systems I've worked on simple don't have enough flash to be able to store
>>> the bootloader, kernel and an initramfs [as well as other system items
>>> required by the devices]. In this case a base rootfs makes the most sense.
>>
>> In my opinion, what's proposed in the two links is a good thing even
>> for embedded. Not that we'd use that structure necessarily, but
>> removing the usr vs non-usr separation for binaries and libs is a good
>> thing regardless. Putting /usr in the rootfs still would still work
>> fine, or you could drop usr entirely and move everything to / the way
>> micro does.
>
> The nice thing is we have a system which can actually support the
> different options relatively easily and without much conflict.
Except that things like fs-perms.txt store hardcoded values :(
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 16:04 ` Chris Larson
2012-01-06 16:12 ` Mark Hatle
@ 2012-01-06 16:16 ` Richard Purdie
2012-01-06 16:43 ` Koen Kooi
1 sibling, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2012-01-06 16:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Fri, 2012-01-06 at 09:04 -0700, Chris Larson wrote:
> On Fri, Jan 6, 2012 at 8:59 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> > On 1/6/12 4:34 AM, Koen Kooi wrote:
> >>
> >>
> >> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
> >>
> >>> FWIW today I've noticed that systemd is going other way around
> >>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> >>
> >>
> >> And http://fedoraproject.org/wiki/Features/UsrMove
> >>
> >> I guess it's time to publish my angstrom branch doing that after the
> >> holidays :)
> >
> >
> > I respectfully disagree with both of the above URLs.
> >
> > The root partition is still very useful as a "small" set of applications and
> > libraries required for booting.
> >
> > Most systems these days contain a combined root and usr partition, which is
> > fine. However, there are a lot of systems that I've worked on in the past
> > and I expect in the future that, root being a small R/O system is necessary.
> >
> > initramfs can solve some problems, but introduces other issues. Many of the
> > systems I've worked on simple don't have enough flash to be able to store
> > the bootloader, kernel and an initramfs [as well as other system items
> > required by the devices]. In this case a base rootfs makes the most sense.
>
> In my opinion, what's proposed in the two links is a good thing even
> for embedded. Not that we'd use that structure necessarily, but
> removing the usr vs non-usr separation for binaries and libs is a good
> thing regardless. Putting /usr in the rootfs still would still work
> fine, or you could drop usr entirely and move everything to / the way
> micro does.
The nice thing is we have a system which can actually support the
different options relatively easily and without much conflict. Each has
its usecases and its relatively simple to set things up to build them as
micro has shown. I believe we can actually do better than other distros,
not just follow them.
Cheers,
Richard
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 16:04 ` Chris Larson
@ 2012-01-06 16:12 ` Mark Hatle
2012-01-06 16:16 ` Richard Purdie
1 sibling, 0 replies; 14+ messages in thread
From: Mark Hatle @ 2012-01-06 16:12 UTC (permalink / raw)
To: openembedded-core
On 1/6/12 10:04 AM, Chris Larson wrote:
> On Fri, Jan 6, 2012 at 8:59 AM, Mark Hatle<mark.hatle@windriver.com> wrote:
>> On 1/6/12 4:34 AM, Koen Kooi wrote:
>>>
>>>
>>> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
>>>
>>>> FWIW today I've noticed that systemd is going other way around
>>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>>
>>> And http://fedoraproject.org/wiki/Features/UsrMove
>>>
>>> I guess it's time to publish my angstrom branch doing that after the
>>> holidays :)
>>
>>
>> I respectfully disagree with both of the above URLs.
>>
>> The root partition is still very useful as a "small" set of applications and
>> libraries required for booting.
>>
>> Most systems these days contain a combined root and usr partition, which is
>> fine. However, there are a lot of systems that I've worked on in the past
>> and I expect in the future that, root being a small R/O system is necessary.
>>
>> initramfs can solve some problems, but introduces other issues. Many of the
>> systems I've worked on simple don't have enough flash to be able to store
>> the bootloader, kernel and an initramfs [as well as other system items
>> required by the devices]. In this case a base rootfs makes the most sense.
>
> In my opinion, what's proposed in the two links is a good thing even
> for embedded. Not that we'd use that structure necessarily, but
> removing the usr vs non-usr separation for binaries and libs is a good
> thing regardless. Putting /usr in the rootfs still would still work
> fine, or you could drop usr entirely and move everything to / the way
> micro does.
I'd prefer if someone wants to flatten the filesystem that they move everything
to '/'. This will still work in the case where we move libraries and binaries
between '/' and '/usr' in the generic case.
This would support both the traditional filesystem split case as well as a more
modern single filesystem case. (We even have the ability, even though I doubt
it's been tested, to change the base_bindir, base_sbindir, base_libdir to be
/usr/bin, /usr/sbin, and /usr/lib* to automatically move the things into /usr if
that is the system someone wants.)
--Mark
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 15:59 ` Mark Hatle
@ 2012-01-06 16:04 ` Chris Larson
2012-01-06 16:12 ` Mark Hatle
2012-01-06 16:16 ` Richard Purdie
0 siblings, 2 replies; 14+ messages in thread
From: Chris Larson @ 2012-01-06 16:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Fri, Jan 6, 2012 at 8:59 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 1/6/12 4:34 AM, Koen Kooi wrote:
>>
>>
>> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
>>
>>> FWIW today I've noticed that systemd is going other way around
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>>
>> And http://fedoraproject.org/wiki/Features/UsrMove
>>
>> I guess it's time to publish my angstrom branch doing that after the
>> holidays :)
>
>
> I respectfully disagree with both of the above URLs.
>
> The root partition is still very useful as a "small" set of applications and
> libraries required for booting.
>
> Most systems these days contain a combined root and usr partition, which is
> fine. However, there are a lot of systems that I've worked on in the past
> and I expect in the future that, root being a small R/O system is necessary.
>
> initramfs can solve some problems, but introduces other issues. Many of the
> systems I've worked on simple don't have enough flash to be able to store
> the bootloader, kernel and an initramfs [as well as other system items
> required by the devices]. In this case a base rootfs makes the most sense.
In my opinion, what's proposed in the two links is a good thing even
for embedded. Not that we'd use that structure necessarily, but
removing the usr vs non-usr separation for binaries and libs is a good
thing regardless. Putting /usr in the rootfs still would still work
fine, or you could drop usr entirely and move everything to / the way
micro does.
--
Christopher Larson
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 10:34 ` Koen Kooi
@ 2012-01-06 15:59 ` Mark Hatle
2012-01-06 16:04 ` Chris Larson
0 siblings, 1 reply; 14+ messages in thread
From: Mark Hatle @ 2012-01-06 15:59 UTC (permalink / raw)
To: openembedded-core
On 1/6/12 4:34 AM, Koen Kooi wrote:
>
> Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
>
>> FWIW today I've noticed that systemd is going other way around
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> And http://fedoraproject.org/wiki/Features/UsrMove
>
> I guess it's time to publish my angstrom branch doing that after the holidays :)
I respectfully disagree with both of the above URLs.
The root partition is still very useful as a "small" set of applications and
libraries required for booting.
Most systems these days contain a combined root and usr partition, which is
fine. However, there are a lot of systems that I've worked on in the past and I
expect in the future that, root being a small R/O system is necessary.
initramfs can solve some problems, but introduces other issues. Many of the
systems I've worked on simple don't have enough flash to be able to store the
bootloader, kernel and an initramfs [as well as other system items required by
the devices]. In this case a base rootfs makes the most sense.
So as I mentioned in my previous email -- there are really three options to
supporting this:
*) Move the libraries from /usr to /
*) Move the binaries from / to /usr
*) Reconfigure the binaries to no longer need the library in /usr
---
But with that said, we also should work on making it easier to generate an
initramfs that is capable of premounting all of the filesystems and doing other
actions for an "early boot" capability before handing off control to the real
system. (And I do believe systemd is the future of initscripts within Linux and
OE-Core for the majority of non-simple systems!)
--Mark
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
2012-01-06 10:09 Martin Jansa
@ 2012-01-06 10:34 ` Koen Kooi
2012-01-06 15:59 ` Mark Hatle
0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2012-01-06 10:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 6 jan. 2012, om 11:09 heeft Martin Jansa het volgende geschreven:
> FWIW today I've noticed that systemd is going other way around
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
And http://fedoraproject.org/wiki/Features/UsrMove
I guess it's time to publish my angstrom branch doing that after the holidays :)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: libs transition /usr/lib -> /lib questions
@ 2012-01-06 10:09 Martin Jansa
2012-01-06 10:34 ` Koen Kooi
0 siblings, 1 reply; 14+ messages in thread
From: Martin Jansa @ 2012-01-06 10:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
FWIW today I've noticed that systemd is going other way around
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-01-22 0:13 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-05 23:29 libs transition /usr/lib -> /lib questions Andreas Müller
2012-01-06 3:35 ` Scott Garman
2012-01-06 13:33 ` Andreas Müller
2012-01-06 10:48 ` Enrico Scholz
2012-01-06 15:48 ` Mark Hatle
2012-01-22 0:05 ` Khem Raj
2012-01-06 10:09 Martin Jansa
2012-01-06 10:34 ` Koen Kooi
2012-01-06 15:59 ` Mark Hatle
2012-01-06 16:04 ` Chris Larson
2012-01-06 16:12 ` Mark Hatle
2012-01-06 16:16 ` Richard Purdie
2012-01-06 16:43 ` Koen Kooi
2012-01-06 16:51 ` Mark Hatle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.