[OpenWrt-Devel] Improving ALL and ALL_KMODS (was Re: [PATCH] scripts/metadata: Allow to select which profiles to build)
nbd at openwrt.org
Tue Jan 12 03:38:46 EST 2016
On 2016-01-12 03:53, Daniel Dickinson wrote:
> Hi Felix,
> On 11/01/16 03:28 PM, Felix Fietkau wrote:
> > This is close to what I had in mind in my earlier response. Yes, it's
> > ugly, but it's a lot less ugly than taking your approach without dealing
> > with the issues that I pointed out.
> Since a bit of ugliness for improved user experience seems to be
> acceptable, how do you feel about the following proposal to deal with
> current brokenness of ALL and ALL_KMODS (specifically that once there is
> an existing .config that selecting/deselecting those options no longer
> does anything; that is they only work when starting with no .config):
> Make ALL a configuration option created by metadata.pl that does select
> <package> for all packages (except kmods), and
> ALL_KMODS a configuration option create by metadata.pl that does select
> <kmod-package> for all kmods and is default y if ALL.
> This generated config could go under tmp and be sourced by
> Config-build.in in the current location of ALL and ALL_KMODS.
> Even though it's kind of ugly, since you dislike the similar issues with
> profile selection as menu enough to accept some ugliness, I'm wondering
> if you could accept some ugliness to make ALL and ALL_KMODS work better
> too (as I'm not sure you'd even realized there was in issue before).
Of course I realized this issue pretty much from the beginning when we
added support for it to the tree.
The problem with forcing ALL and ALL_KMODS to select packages is that it
makes it difficult to deselect a package afterwards.
Also unlike the profile case, those options are typically selected when
you start building a configuration for a device, not so much after
you've already configured everything.
So while there are superficial similarities with the profile issue,
there are enough differences in how it gets used by users that we should
treat it differently.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel