[oe] USE flags - why they won't work for OE

[Darcy Watkins]

Hello,

My two bits worth (Canadian - now almost at par with US currency.  ;-)

In the buildroot project, they use:

  $ make menuconfig

... to configure the system to be built and to select packages.  Then it
is all built up using auto configure type tools.  In fact, they even
have targets at the buildroot Makefile level that allow running the
menuconfig target for uclibc and busybox.

Perhaps an OE distro could provide the default answers to a similar
scheme, but the user should be able to run the menu config to change the
choices.  It would also be cool if the "lite" and other options could be
default rule filters to apply to a distro to change the default choices
before invoking the menu config.

After this, the build process should still check for dependencies and
include those needed but which were not chosen.  This has the added
benefit that if you remake down the road after removing packages, any
dependencies no longer needed would no longer be included.

It would be nice to run something like:

  <utilname>  DISTRO=angstrom.2007.1 MACHINE=myppcbox \
    DEFAULTS=uclibc-lite,busybox-lite,packages-lite,secure-web-lite

...etc.  The filters could be run in some agreed order (e.g. left to
right) so it will be well understood how conflicts between filter files
will be resolved.

It would generate some .bb files to be included.  Then away to the
races...

An alternative would be to list the filters in the local config file and
just have bitbake invoke the menuconfig program when it detects a change
made to the list of filters.  For those who hate having the build
process launch an interactive application, have an
abort-on-config-change provision with output instructing the user to
manually run a menuconfig program.

I understand that there is value to consumer handheld devices to have a
package manager to run on the target to install and upgrade
applications, but that isn't of much use to smaller embedded appliances
where it is more important that the vendor strictly control the software
configurations that their support team will handle.  In such cases,
software upgradeability is typically managed more at the level of
filesystem images than as individual files and it is rare that the end
user is able to change anything other than user settings and preferences
stored in some form of a database.


Regards,

Darcy