[oe] [PATCH 2/2] grub: allow menu.lst to be overridden using GRUB_CONFIG_PACKAGE.

[Michael Smith]

Phil Blundell wrote:
> On Wed, 2009-05-06 at 18:38 -0400, Denys Dmytriyenko wrote:
>> On Wed, May 06, 2009 at 03:55:57PM -0400, Michael Smith wrote:

>> It was discussed many times here - no USE flags in OE.
> 
> Although you're right that it comes up here frequently, I think this "no
> USE flags" dogma is somewhat misguided.  It seems, frankly, absurd to
> require people to effectively fork a recipe whenever they want to make
> some or other configuration change.

I agree. If OpenEmbedded is a toolset for building distributions, rather 
than just a single distribution, then it'd be great if there were an 
easy way for distribution builders to make different packaging choices 
than the ones that have been made for Angstrom, without maintaining a 
forked copy of everything.

There might be ways to do it without USE flags. I think some tweaks to 
the overlay mechanism would help here. First, if I could create a 
package in an overlay that references files from the upstream in 
SRC_URI, I wouldn't have to copy all the patches, initscripts, etc. over 
to the overlay. For example, if my tree looks like the one below:

top/
  |-- local (overlay)
  |   `-- recipes
  |       `-- grub
              |-- grub_0.97.bb (overlay)
  |           `-- files
  |               `-- menu.lst (overlay)
  `-- openembedded (upstream)
      `-- recipes
          `-- grub
              |-- grub_0.97.bb (upstream)
              `-- files
                  |-- menu.lst (upstream)
                  `-- some.patch (upstream)

My grub_0.97.bb could reference file://some.patch in its SRC_URI and 
bitbake could look in the next COLLECTION after failing to find it in 
the local one. In fact, I wouldn't even really need a bbfile in the 
overlay; just having files/menu.lst in the overlay could be enough to 
replace it. I guess this might just require some fudging to how 
FILESPATH is set up in base.bbclass.

Second, if a recipe could include a recipe of the same name and let 
bitbake search for it in the next COLLECTION, overlay packages could get 
a lot smaller. Say I need to add a private patch to grub -- my overlay 
grub_0.97.bb, if I had one, could just look like this:

require_next ${PN}/${PN}_${PV}.bb
SRC_URI += "file://some-private.patch;patch=1"

Something similar might be useful for INHERIT. Instead of creating an 
overlay bbfile for linux_${PN}.bb, I could just override kernel.bbclass 
and then pull in the original.

Is this something people would be interested in, or am I making it more 
complicated than it needs to be?

Mike