Re: Parameterized packages

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Hi Marius!

Marius Bakke <mbakke@fastmail.com> writes:

> Having used Gentoo for some years, I'm not sure a "global" parameter
> system is desirable.  It could encourage enabling feature "foo", even
> for packages that have experimental or broken support for "foo".

That said, the recursive activation of parameters that you mention below
has the same "compatibility" drawback (that I mentioned in my previous
email) as global parameters.

More below:

> (inputs
>   `(("foo" ,foo))
>     ("bar" ,(with-parameters ((pulseaudio . #f)) bar)))
>
> We could have a similar procedure that recursively toggles supported
> parameters of all given packages.

Breaking example:

--8<---------------cut here---------------start------------->8---
(with-recursive-parameters ((pulseaudio .#f)) bar)
--8<---------------cut here---------------end--------------->8---

with `bar' breaking if one of its dependencies has pulseaudio disabled.

To be usable, we would need something to say "build bar and all its
inputs without pulseaudio, except for some given packages".

While this is OK with 1 parameter, it's quickly gets much more
complicated when packages have multiple parameters that maybe conflict
with one another.

Does that make sense?

Both from the packager and the user point of view, this is the
combinatorial problem of what sets of parameters are compatible.  (Same
problem on Gentoo)

I can't think of a way to fix this beside the packagers encoding
themselves each set that works.

> Actually we can abuse the 'properties' field for this purpose without
> having to change anything.

Can you detail what do you have in mind?  Earlier in this thread it was
mentioned that leveraging `properties' would not be a good idea.


Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]