All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.