From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: libs transition /usr/lib -> /lib questions
Date: Fri, 6 Jan 2012 10:12:38 -0600 [thread overview]
Message-ID: <4F071D76.3070803@windriver.com> (raw)
In-Reply-To: <CABcZANk=sg=oj+KyVcBF=UoC460EV-QtiW4B=wKXPBSLrV4HOQ@mail.gmail.com>
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
next prev parent reply other threads:[~2012-01-06 16:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 10:09 libs transition /usr/lib -> /lib questions 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 [this message]
2012-01-06 16:16 ` Richard Purdie
2012-01-06 16:43 ` Koen Kooi
2012-01-06 16:51 ` Mark Hatle
-- strict thread matches above, loose matches on Subject: below --
2012-01-05 23:29 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F071D76.3070803@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.