Duplicate recipes in meta-oe

Duplicate recipes in meta-oe

[Khem Raj]

Hi

Following recipes are duplicated in meta-oe

recipes-devtools/python/python-imaging_1.1.7.bb
recipes-devtools/python/python-setuptools_0.6c11.bb
recipes-core/eglibc/ldconfig-native_2.12.1.bb
recipes-graphics/xorg-app/rgb_1.0.4.bb
recipes-extended/tzcode/tzcode-native_2011i.bb
recipes-multimedia/libmad/libmad_0.15.1b.bb
recipes-extended/cups/cups_1.4.6.bb

lets try to find the differences and consolidate them and move them to
either oe-core or meta-oe
where ever they are more suitable.

Thanks
-Khem

Re: Duplicate recipes in meta-oe

[Khem Raj]

On Sat, Feb 4, 2012 at 9:12 AM, Khem Raj <raj.khem@gmail.com> wrote:
> Hi
>
> Following recipes are duplicated in meta-oe
>
> recipes-devtools/python/python-imaging_1.1.7.bb
> recipes-devtools/python/python-setuptools_0.6c11.bb
> recipes-core/eglibc/ldconfig-native_2.12.1.bb
> recipes-graphics/xorg-app/rgb_1.0.4.bb
> recipes-extended/tzcode/tzcode-native_2011i.bb
> recipes-multimedia/libmad/libmad_0.15.1b.bb
> recipes-extended/cups/cups_1.4.6.bb
>

I sent a patch to delete obvious ones from meta-oe but following still
needs to be looked at
recipes-devtools/python/python-imaging_1.1.7.bb

the above recipes apply same patch but meta-oe has extra  stuff in
do_install which probably should go into oe-core and pr scheme is
different mlX Vs rX so that will change

recipes-devtools/python/python-setuptools_0.6c11.bb

one in meta-oe has
NATIVE_INSTALL_WORKS = "1"
I dont know if this is needed anymore if not then this can be delete
from meta-oe

recipes-extended/tzcode/tzcode-native_2011i.bb

We are good with one for oe-core I think Andrea is working on it.

recipes-multimedia/libmad/libmad_0.15.1b.bb

meta-oe has

-           file://fix_for_mips_with_gcc-4.5.0.patch"
+           file://mad.diff \
+           file://mad-mips-h-constraint.patch"
+
+SRC_URI_append_avr32 = " file://libmad-0.15.1b-avr32-optimization.patch"

fix_for_mips_with_gcc-4.5.0.patch and mad-mips-h-constrain.patch are
essentially fixing same thing

mad.diff disables certain optimizations I dont think we need that

so I think this can be converted into a bbapend for avr
SRC_URI_append_avr32 = " file://libmad-0.15.1b-avr32-optimization.patch"



> lets try to find the differences and consolidate them and move them to
> either oe-core or meta-oe
> where ever they are more suitable.
>
> Thanks
> -Khem

Re: Duplicate recipes in meta-oe

[Paul Eggleton]

On Saturday 04 February 2012 10:19:38 Khem Raj wrote:
> recipes-devtools/python/python-setuptools_0.6c11.bb
> 
> one in meta-oe has
> NATIVE_INSTALL_WORKS = "1"
> I dont know if this is needed anymore if not then this can be delete
> from meta-oe

NATIVE_INSTALL_WORKS is no longer needed for OE-Core, so this can go.
 
> recipes-extended/tzcode/tzcode-native_2011i.bb
> 
> We are good with one for oe-core I think Andrea is working on it.

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?
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] Duplicate recipes in meta-oe

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Mon, Feb 6, 2012 at 13:39, Paul Eggleton
<paul.eggleton@linux.intel.com>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 don't think this is worth to be selectable.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: Duplicate recipes in meta-oe

[Phil Blundell]

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.

p.

Re: Duplicate recipes in meta-oe

[Koen Kooi]

Op 6 feb. 2012, om 16:55 heeft Phil Blundell het volgende geschreven:

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

That was my reasoning as well.

regards,

Koen

Re: Duplicate recipes in meta-oe

[Philip Balister]

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?

Philip

Re: Duplicate recipes in meta-oe

[Mark Hatle]

On 2/6/12 1:43 PM, 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?

Where I have seen it is on some carrier grade blade systems.  Each blade has a 
small local boot partition, which a shared (read-only) /usr partition.  The 
small boot partition handles initial booting, setup and mounting.. while the 
shared partition handles the majority of "unix infrastructure".

These systems do not use ramdisks, initrds, etc...

I'm also aware of some other systems that do this for boot performance reasons.. 
they do it for booting quickly to the main UI app, and in parallel mounting and 
loading additional runtime apps from the /usr disk (RO) and a /var (RW) disk. 
As things are available the UI options are made available to the end user.  The 
result is a -faster- perceived boot.  Again ramdisks/initrds are not used 
because of various reasons.

--Mark

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

Re: Duplicate recipes in meta-oe

[Phil Blundell]

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.

Re: 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Duplicate recipes in meta-oe

[Phil Blundell]

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.

Re: Duplicate recipes in meta-oe

[Khem Raj]

On Mon, Feb 6, 2012 at 12:20 PM, Phil Blundell <philb@gnu.org> wrote:
> 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.

well said Phil I have always been in favor of doing something like
that instead of unconditionally ramming patches down the throats of
different packages to support it
since it does come with maintenance cost.

Re: Duplicate recipes in meta-oe

[Mark Hatle]

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