Re: [RFC] Allarch and packagegroup improvement proposal

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2014-08-19 at 12:41 +0200, Koen Kooi wrote:
> Op 18 aug. 2014, om 17:35 heeft Richard Purdie <richard.purdie@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?

libfoo

Its very unlikely someone would write a package which the namespaces
conflicted in the way we use things currently.

The other related question is whether we should be doing automatic
remapping in RPROVIDES/RREPLACES/RCONFLICTS ?

Since at the moment if we put libfoo into RPROVIDES, it gets mapped to
libfoo5 by the remapping code...

I have patches which make various things work, I'll probably post them
and people can see what they think. 

Cheers,

Richard