From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: libs transition /usr/lib -> /lib questions
Date: Fri, 06 Jan 2012 16:16:55 +0000 [thread overview]
Message-ID: <1325866615.14746.4.camel@ted> (raw)
In-Reply-To: <CABcZANk=sg=oj+KyVcBF=UoC460EV-QtiW4B=wKXPBSLrV4HOQ@mail.gmail.com>
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
next prev parent reply other threads:[~2012-01-06 16:24 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
2012-01-06 16:16 ` Richard Purdie [this message]
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=1325866615.14746.4.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox