2011/11/19 Martin Jansa <martin.ja...@gmail.com> > On Sat, Nov 19, 2011 at 04:02:49PM +0100, Frans Meulenbroeks wrote: > > 2011/11/18 Paul Eggleton <paul.eggle...@linux.intel.com> > > > > > On Friday 18 November 2011 15:28:28 Frans Meulenbroeks wrote: > > > > Is ordering of PACKAGES relevant? If so, please enlighten me why. > > > > > > It is. The packaging code reads this in order and the first package to > > > match a > > > file is the package that the file will go into; thus if you want to > add a > > > package that will include files that would normally be in one of the > > > default > > > packages you need to prepend to PACKAGES so that your new package gets > the > > > files first. > > > > > > Ah, ok. understood. > > Not fully sure if the current behaviour is the most desirable one. > > Is it still possible to put a file into two packages by explicitly adding > > it to both? > > And then make resulting packages RCONFLICTing each other? Imho this is > bad idea and it's good that this wasn't ever possible afaik. > I was thinking of the situation where a recipe could generate two (indeed conflicting) packages. E.g. a minimal version and a more expanded version. Or versions with different options enabled. Or a static and a dynamic linked version (which still could share e.g. a common config file). I can also imagine one wants (or must) add a file to all packages. This could perhaps apply to some license files.
> Also it might be somewhat confusing that a line that adds say a dir to a > package does not necessarily get all fies in that dir in the package > Personally I think I prefer to have all added in that case, irrespective if > a previous package already took a file from it. Why confusing? > should only one package include all /usr/lib/foo and then separte > subpackages package only some parts of it so we won't pull whole big > /usr/lib/foo when we need in some image only > /usr/lib/foo/feature1 and /usr/lib/foo/feature2 in other package? And > what should shlibs report as feature1 provider? PN_feature1 or PN (which > also includes all /usr/lib/foo/feature1 files)? > > Sorry but this idea seems wrong to me.. > I'm not saying we should move into that direction, I'm more exporing whether there is a use case for this and whether it is desired or not. If it is felt that allowing adding a file to two packages is not good, then I feel that if a file could be candidate for insertion of two packages, this could be flagged as an error to be resolved in the recipe (by more precisely specifying the package contents). That way ordering within PACKAGES becomes irrelevant (and as such it removes a source of silent errors, like the one that started this thread). Frans. > > Alternately it could be seen as a QA issue if a file could have been > added > > to two packages (in which case a more strict pattern should have been > used > > somewhere) > > > > Frans > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core