[oe] Yocto Project and OE - Where now?

[Frans Meulenbroeks]

2011/1/18 Tom Rini <tom_rini at mentor.com>:
> On 01/18/2011 02:12 AM, Graeme Gregory wrote:
> [snip]
>
>> Ill also point out that gentoo which is probably closest to OE in
>> management of metadata does not pathalogically delete old versions.
>
> This brings up a good point.  One of the reasons for deleting old versions
> is the headache that is often involved in recipe-bug-fixing.  I didn't
> exactly mind, but nor did I enjoy changing 10 versions of gcc at times when
> fixing some issues here and there.  Perhaps we need to be way more zealous
> in our use of .inc files, and default to doing say busybox-1.18.x.inc,
> busybox_1.18.0.bb, busybox_1.18.1.bb and so on?  Put the patches / checksums
> into the version file (and ok, really really version specific fixups), put
> the meat into the .inc file and not be afraid of having a few levels of
> inclusion at times?

The issue with inc files is that if you fix a bug you should at least
build, but preferably also test that all versions still work.
Too often patches are applied and tested with the latest version,
leaving broken older recipes (recipes that were not broken before the
inc file was modified).
Personally I prefer not having an inc file. The downside of not having
an .inc file is that if you add a patch you might need to update a few
.bb files. This is in most cases a fairly trivial job.
The upside of not having an .inc file, is that it increases the chance
that the patch is indeed verified by the person who applied it. Also I
feel that having all info in one place slightly increases the
accessibility and readability.

BTW; the effort of adding a patch to the SRC_URI in say 3 .bb files is
neglectable compared to the time needed to verify and test the patch.
(or course unless you do not care about testing all versions, but then
you're probably more contributing to the problem than to the solution.

And for the .inc files that we have (because some of them do make
sense, gcc probably being *the* example), it seems good to have some
guidelines what goes in it and what not.
E.g. I have seen people adding things like HOMEPAGE into their inc
file. Is that desired? Some of our inc files have it, others don't.
And make them e.g. consistent wrt the usage of INC_PR. Currently we
have in OE about 930 .inc files. About 260 of them have INC_PR.

I feel instead of moving whatever we have to meta-oe as soon as they
are buildable under yocto, we should take the opportunity to do a
sanity check and cleanup on these and make them more uniform.

Frans.

PS: perhaps the ultimate form of using an inc file is to have *all*
metadata in the inc file, and let the recipe degenerate to include
foo.inc (or symlink foo_X.bb to foo.inc; saves the include statement
:-) )

PPS: probably the most pathetical case of inc files is
glibc/glibc-stage.inc (which is empty) followed by radlib/radlib.inc
(which is a oneliner saying EXTRA_OECONF = " --host=${TARGET_SYS}
--prefix=${STAGING_DIR_HOST}${layout_prefix}"