On Tue, 2014-08-19 at 12:41 +0200, Koen Kooi wrote: > Op 18 aug. 2014, om 17:35 heeft Richard Purdie > <richard.pur...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
