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

[Phil Blundell]

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:
> > If GRUB_CONFIG_PACKAGE is set, don't ship menu.lst with grub. Instead,
> > RRECOMMEND the config package. This allows overlays to override menu.lst
> > in a separate package, rather than copying the whole grub package into
> > the overlay.
> 
> It was discussed many times here - no USE flags in OE. You'll end up with 2 
> grub packages of the same name but with different contents - with menu.lst 
> and without.

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.  Firstly, this is just tiresome to
do; secondly, it leads to source tree clutter and corresponding
maintenance headaches because you end up with large numbers of
possibly-defunct recipes lying around; and thirdly it leads to a worse
end-user experience because suddenly their binary packages end up with
crazy names that encode some aspect of the distro configuration. 

Also, it simply isn't reasonable to expect that you can encode
everything about a binary package into its filename: there are too many
unknown inputs for this to be feasible.  If you want to know whether two
packages are the same then you should compare the md5sums, and if it's
vital (for whatever reason) for you to have an unambiguous, unique
fingerprint for each binary package then you should probably consider
making the md5sum be part of the output filename.

I do understand the desire to have package builds be repeatable and
deterministic, and that's clearly a reasonable thing to want.  But USE
flags at the recipe level don't materially alter the situation here: if
you use a given distro configuration, unmodified, then you're going to
get the same values of the USE flags as everybody else who builds for
that distro.  If you start randomly flipping USE flags in your local
copy of the distro configuration or overriding them from local.conf then
sure, you will lose, but if your source tree contains arbitrary local
hacks then there already countless ways in which you could lose by, for
example, selecting a different compiler, C library or global build
options to everybody else.

And, indeed, we do already have a certain number of USE-type flags in OE
today: the most obvious one that comes to mind is
ENABLE_BINARY_LOCALE_GENERATION, which impacts the way that glibc is
packaged and yet doesn't seem to be causing any significant grief at the
moment.

p.