[OE-core] Duplicate recipes in meta-oe

[Mark Hatle]

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:
>>> 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.

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.

With that said, a check was added to the oe-core a while back to generate a 
warning with a shared library, or shell script "obviously" referenced an item 
from /bin, /sbin, /lib to /usr/*.  Both of which are warnings.  On a system 
where there is no /usr  (i.e. execprefix is "/") then no warnings are given.

The issue that needs to be solved is that there is no reason this shouldn't 
work.  Things need to be adjusted so the right files are on the right 
partitions, and beyond that the system is still functional.  (Definition of 
function to -me- is can minimally boot and get to a shell... there should be 
enough there to mount /usr and enable a full system -- if /usr is a separate 
partition.)

My personal expectations are that /bin, /sbin, /etc, and /lib are all on "/". 
Anything else can be mounted from virtual systems or actual partitions.  I do 
agree the majority of designs these days will have most if not all items on the 
same partition.  (Possible exception of some /var elements.)

The problem with my expectations though.. we can automatically check for the 
things we already do.. (symlinks and above greps).  But what we can't easily 
check for is things being dynamically loaded or run from say the init program. 
These are the true "bugs" that I see in the system.  Things we need to figure 
out and resolve.

In the end it's going to enable a more configurable system.  Nothing being done 
to support this should ever preclude a system with a single partition or a 
system where base_prefix and exec_prefix are equal.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core