From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Duplicate recipes in meta-oe
Date: Mon, 6 Feb 2012 17:38:10 -0600 [thread overview]
Message-ID: <4F306462.5070201@windriver.com> (raw)
In-Reply-To: <1328567740.2716.238.camel@x121e.pbcl.net>
On 2/6/12 4:35 PM, Phil Blundell wrote:
> 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.
Most of the (older?) distributions I know of run a program that copies the file
if it's a different partition or does a hard link if it's the same partition.
This falls apart of a bit in the rootfs construction because there is currently
no concept of "partitions".
I'm not even sure if the zone file is relevant for any of the early boot
situations. There is no reason it can't be a symlink, as long as programs and
the libc ignore it and use GMT otherwise.
--Mark
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
next prev parent reply other threads:[~2012-02-06 23:46 UTC|newest]
Thread overview: 13+ 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:47 ` [oe] " 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
2012-02-06 23:38 ` Mark Hatle [this message]
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=4F306462.5070201@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox