Subject: Parameterized packages

From: Ludovic Courtès <[email-masked]>
Date: Fri, 11 Jul 2025 09:29:24 +0200

Hi,

David Elsing <[email-masked]> writes:

> Ludovic Courtès <[email-masked]> writes:
>
>> Oh, I see.  The GSoC project you’re referring to was very nice but IMO
>> went a bit too far in terms of what it provides; but the main factor for
>> it being discontinued is that the intern walked away after the
>> internship I believe, and nobody picked it up.  FWIW, I was advocating
>> for something simpler and that would try to reduce the risks of
>> combinatorial explosion¹.
>
> Ah ok, that makes sense. Would it be possible for multiple packages to
> share the same parameter, so that it can be set for all dependencies of
> a package? I guess it should be doable with `package-mapping'.
> I'm also not sure the full Cartesial product of all possible parameters
> should always need to be supported, as it might or some combinations
> don't make sense, so I think there should be a way to specify the
> supported combinations (which isn't the case for both proposals IIUC).

Yes, what I was proposing was to have both global and per-package
parameters.  Global parameters would be things like ‘x11-support?’,
whose value would be the same for all the affected packages (either all
of them are built with X11 support or none of them is).

> Yes I agree that using SRFI-39 parameters is not very suitable for
> parameterized packages. My idea was just to fix `with-parameters' until
> parameterized packages are implemented properly, but it makes sense if
> you don't want to support and later deprecate this.
> Maybe `with-parameters' and `<parameterized>' should be renamed if they
> only support `%graft?', `%current-system' and `%current-target-system'?

Yes, but I can’t think of a better name, and renaming would entail
deprecation etc.  Naming is hard.  :-)

Thanks,
Ludo’.