On Wed, May 18, 2011 at 8:53 AM, Phil Blundell <[email protected]> wrote: > On Tue, 2011-05-17 at 13:57 -0700, Khem Raj wrote: >> With default-setup being pulled in via bitbake.conf and task-core-boot >> being pulled into all images in distros, we need >> to have some variables that distro's can override if need be >> This is a backport from angstrom/OE. It will help distros which >> e.g. would like to use busybox-mdev instead of udev and similarly >> for login manager these variables can be defined in distro policies > > I'm not massively convinced that this proliferation of extra switches is > a very good thing. With each DISTRO now having its own layer, it's > quite straightforward for it to provide its own customised rootfs > recipes which contain exactly the set of packages that it wants. Trying > to create a sort of "generic" rootfs recipe in which every other > dependency can be tweaked by some obscure variable doesn't seem like an > especially productive way to proceed. >
Problem I have is, I dont want udev in RDEPENDS which is added by task-core-boot and task-core-boot is added to DISTRO_EXTRA_RDEPENDS through default-distrovars.inc -> defaultsetup.conf -> bitbake.conf and my distro adds DISTRO_EXTRA_RDEPENDS to its RDEPENDS as I think the variable is meant for distro's to define some extra stuff if needed. How should I solve this problem ? > Also, any new variable which is added to default-distrovars.inc will be > included in the parsed metadata for everything and, although the > marginal cost (in memory/performance terms) of adding one extra global > variable is not that great, it's not zero either. Perhaps more > significantly, there is also a cost in terms of metadata > comprehensibility: one of the common complaints about "classic oe" was > that it was difficult to get your head around the myriad little > variables that you could tweak in some or other configuration file. > > So, all in all, I think we should try to keep a lid on the amount of > stuff that goes into default-distrovars and its friends. If the idea of > a sort of templated rootfs image really seems like a valuable one then > maybe we could put those vars in a dedicated config file which is only > included by the rootfs recipes. > > p. > > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
