[OE-core] [RFC] Allarch and packagegroup improvement proposal

[Koen Kooi]

Op 18 aug. 2014, om 17:35 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:

> On Mon, 2014-08-18 at 15:39 +0100, Richard Purdie wrote:
>> On Mon, 2014-08-18 at 15:14 +0200, Martin Jansa wrote:
>>> Well then maybe that allarch package with perl dependency shouldn't be
>>> marked as allarch.
>> 
>> Take a step back and think about this from the end user system
>> perspective. The packages are all identical for each architecture,
>> "perl" doesn't change name. 
>> 
>> To me that means the correct end result is such a package should be
>> "allarch" in the package feeds.
>> 
>> The question then becomes, how do we generate such things in a sane way.
>> 
>>> I'm in favor of removing default allarch and setting correct
>>> PACKAGE_ARCH manually in the packagegroup recipes like we do elsewhere.
>>> 
>>> packagegroups are small and "rebuilt" quickly, so I don't mind
>>> "building" them once per TUNE_PKGARCH or even once per MACHINE_ARCH like
>>> we do for couple of them already.
>>> 
>>> I can even find few changes from me on ML which do exactly that.
>> 
>> It does seem a bit of a cop out to do this on the grounds that its
>> small/fast :/.
>> 
>> I agree there is good reason why some should be PKGARCH but we can
>> probably do better than just marking them all that way IMO. I think we
>> should try and mark them correctly too, i.e. think about whether the
>> packages really are identical and/or make sense as allarch and try and
>> avoid duplication if so.
> 
> I also have one other idea. We could adjust debian.bbclass so that it
> adds an RPROVIDES for the original package name. We could then instruct
> packagegroups specifically not to adjust the naming for debian renaming.
> 
> This would mean that the packagegroups would know the dependencies by
> their non-debian, unversioned name.
> 
> Would that work for people?
> 
> I'm torn on the idea right now but thought I'd share it.

What happens in the following situation:

foo.bb generates foo.ipk (/usr/bin/foo) and libfoo5.ipk (/usr/lib/libfoo.so.5), will libfoo5 RPROVIDE 'foo', 'libfoo' or something else?

regards,

Koen