Re: A plan for parameterized packages

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> For the embedded/flash rom side:

Note: it’s great if it can help reduce closure size, but that’s not the
goal.

> * Enable/disable building the documentation.  I really don't need a 40 MiB
> manual stored onto a 16 MiB firmware flash chip.  If that's better done as an
> extra output, fair enough.

Extra output is better, yup.  :-)

> * Enable/disable obscure dependencies: Library packages that pull in 400 MiB Qt
> into the closure for a thing no one (TM) uses should probably provide a switch to
> disable that GUI.  Sometimes a package provides multiple GUIs for different
> toolkits, in which case one should be able to choose one toolkit and not
> build for the others.

Yes, that sounds like a good use case.

> * No, even in 2020, I won't start using AmigaFS, NFSv3 and whatever old
> protocol/format is still around and superseded by other protocols.
>
> The gexp-functionality of being able to select individual files of a package
> is already very useful for use cases an embedded developer would have
> (and that's there for a long time already).  So that's nice!
>
> For the kind of feature flags I have in mind, it usually means I don't want
> to have the feature *anywhere*--for example, if I don't want to have Qt or
> Kerberos or whatever, that's because I want to save the space and thus
> it should be able to be *globally* specified--at least per profile.

OK, so that’s similar to what Pierre was suggesting: “global”
parameters, or at least parameters that apply to all the packages that
know about it, not just to one package.

Sounds doable, but again, the challenge will be to build all the
combinations.

> I would advise against doing a grep -r -- --enable and introducing all those
> as parameters.  Rather I would check the closure of stuff and if the closure
> goes from 1200 MiB to 50 MiB, chances are a parameter would be nice there :)

Heh, sounds like a valid criterion.

I guess initially we’ll have to use them sparsely (in Guix proper) so we
can gain experience with them.

> From experience with Gentoo before I can tell you that the combinatory
> explosion is a real problem and most of the "more advanced" (toggled more
> switches :) ) combinations did not work the majority of the time.

Right, and that’s precisely what I’d like to avoid, at least for the
packages in Guix proper (authors of external channels might have a
different policy.)  So I suppose in Guix we’d have a policy of using
them sparsely, and only/primarily in leaf packages.

Thanks,
Ludo’.