Re: libs transition /usr/lib -> /lib questions

[Mark Hatle <mark.hatle@windriver.com>]

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