From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Duplicate recipes in meta-oe
Date: Mon, 06 Feb 2012 22:35:40 +0000 [thread overview]
Message-ID: <1328567740.2716.238.camel@x121e.pbcl.net> (raw)
In-Reply-To: <4F303C92.8050706@windriver.com>
On Mon, 2012-02-06 at 14:48 -0600, Mark Hatle wrote:
> On 2/6/12 2:20 PM, Phil Blundell wrote:
> > On Mon, 2012-02-06 at 14:43 -0500, Philip Balister wrote:
> >> On 02/06/2012 10:55 AM, Phil Blundell wrote:
> >>> I think probably the right answer is to make "1970s-usr" be a
> >>> DISTRO_FEATURE and then the timezone recipes (and others) can adapt
> >>> themselves accordingly.
> >>
> >> Does anyone use a system where /usr is on a separate partition?
> >
> > I'm not aware of any systems that work that way, but I do know that
> > there have been some patches submitted recently (by Intel folks I think)
> > to move files around in order to avoid binaries in / linking against
> > shared libraries in /usr. Presumably the fact that they're running into
> > these issues indicates that they've got some systems which are using
> > that sort of filesystem configuration.
> >
> > And, given that the idea of a separate /usr does still have some
> > currency in the Unix world, it doesn't seem unreasonable for oe-core to
> > support it. But equally, where that support carries a cost, I think it
> > would make sense for there to be an easy way for DISTROs to opt out of
> > it. Obviously in the case of micro the idea of a separate /usr is
> > meaningless, but I imagine there are plenty of folks who would want to
> > keep the /usr filesystem layout but don't need to take special measures
> > to cope with it being on a different storage device.
>
> All existing patches should support / and "usr" being merged as in the micro
> system design. If that doesn't work, it's an error in the recipe integration.
Yes, agreed. I think there are a few bugs in this area right now (and
Mike Crowe sent some patches today for things which got broken in micro
by the recent changes for separate /usr) but broadly speaking you're
right, there is no reason that the two things can't be supported in
parallel.
The point I was trying to make in the text above was that, in cases like
the timezone thing where there is a real cost to supporting a separate
partition for /usr (i.e. making a copy of the file rather than a link)
it would be desirable for there to be a mechanism for DISTROs which
don't need/want that support to avoid taking the hit.
p.
next prev parent reply other threads:[~2012-02-06 22:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-04 17:12 Duplicate recipes in meta-oe Khem Raj
2012-02-04 18:19 ` Khem Raj
2012-02-06 15:39 ` Paul Eggleton
2012-02-06 15:39 ` [OE-core] " Paul Eggleton
2012-02-06 15:47 ` [oe] " Otavio Salvador
2012-02-06 15:47 ` [OE-core] " Otavio Salvador
2012-02-06 15:55 ` Phil Blundell
2012-02-06 16:07 ` Koen Kooi
2012-02-06 19:43 ` Philip Balister
2012-02-06 20:02 ` Mark Hatle
2012-02-06 20:20 ` Phil Blundell
2012-02-06 20:48 ` Mark Hatle
2012-02-06 22:35 ` Phil Blundell [this message]
2012-02-06 23:38 ` Mark Hatle
2012-02-06 22:59 ` 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=1328567740.2716.238.camel@x121e.pbcl.net \
--to=philb@gnu.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 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.