All of lore.kernel.org
 help / color / mirror / Atom feed
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 20:20:52 +0000	[thread overview]
Message-ID: <1328559652.2716.217.camel@x121e.pbcl.net> (raw)
In-Reply-To: <4F302D77.7030902@balister.org>

On Mon, 2012-02-06 at 14:43 -0500, Philip Balister wrote:
> On 02/06/2012 10:55 AM, Phil Blundell wrote:
> > On Mon, 2012-02-06 at 15:39 +0000, Paul Eggleton wrote:
> >> I talked to Koen at FOSDEM and apparently he prefers having a symlink rather 
> >> than a copy for the timezone file. I can't express an opinion one way or 
> >> another but it sounds like this one aspect still needs to be resolved - should 
> >> this be selectable?
> > 
> > I guess this is all bound up with the "/usr on a separate partition"
> > thing.  If your position is that the root filesystem is meant to work
> > without /usr mounted then having /etc/localtime be a symlink
> > into /usr/share is probably not going to fly.  Conversely, one were to
> > take the view that any reasonable system in the 21st century is going to
> > have / anḍ /usr on the same device, making it be a symlink would be a
> > fine idea.
> > 
> > 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.

p.





  parent reply	other threads:[~2012-02-06 20:29 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 [this message]
2012-02-06 20:48           ` Mark Hatle
2012-02-06 22:35             ` Phil Blundell
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=1328559652.2716.217.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.