[OE-core] [PATCH] shared-mime-info: fix ordering of PACKAGES

[Frans Meulenbroeks]

2011/11/19 Martin Jansa <martin.jansa at gmail.com>

> On Sat, Nov 19, 2011 at 04:02:49PM +0100, Frans Meulenbroeks wrote:
> > 2011/11/18 Paul Eggleton <paul.eggleton at 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 at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111120/58c2de87/attachment-0002.html>