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

[Richard Purdie]

On Mon, 2014-08-18 at 15:14 +0200, Martin Jansa wrote:
> On Mon, Aug 18, 2014 at 01:46:50PM +0100, Richard Purdie wrote:
> > As some people are already painfully aware, the current way packagegroup
> > and allarch interact with the sstate signatures is painful.
> > 
> > Some example problem cases:
> > 
> > * An allarch package of scripts with an interpretor dependency (e.g perl)
> > 
> > * A packagegroup with dependencies on something which is debian renamed 
> >   e.g. build-essentials on libgmp 
> > 
> > 
> > Currently, packagegroups default to allarch and have their sstate
> > dependencies truncated. This means that when something like gmp
> > rebuilds, it can change package name thanks to debian renaming but the
> > packagegroup referencing the old name remains, causing image creation
> > failures.
> > 
> > So the "obvious" fix is to stop truncating the dependencies? Well, that
> > means that the allarch package is written out every time machine changes
> > to a different arch.
> > 
> > So we need to make packagegroups PACKAGE_ARCH specific? Well, this still
> > doesn't solve the problem of allarch packages having ever greater
> > problems with things like dependencies on perl.
> 
> 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.

Cheers,

Richard