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. I did look into and have code for making the allarch inherit conditional, the only issue is that you need to set PACKAGE_ARCH before the inherit packagegroup and no recipes currently do this, its exactly the opposite situation. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
