[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parameterized packages

From: Mark H Weaver
Subject: Re: Parameterized packages
Date: Fri, 17 May 2019 14:15:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)


Tobias Geerinckx-Rice <address@hidden> writes:

> Ludovic Courtès wrote:
>> While thinking about <> and
>> looking
>> for ways to allow users to install just the locales they need right
>> from
>> ‘guix package’, I realized that “parameterized packages” are a
>> low-hanging fruit
> Wow.  Unexpected turn…
> I'm still thinking about this, so all this is just me doing it out
> loud:
>>   (package
>>     (inherit glibc-utf8-locales)
>>     (properties `((locales . ("zh_CN.utf8")))))
>> and tadaam! we have a parameterized package.
>> There’s a couple of gotchas:
>>   • We’d need to store more info in manifest entries so that
>>     transformation options are preserved upon ‘guix upgrade’.
>>   • We might need to expose the package parameters somehow, so
>> that if
>>     one types ‘--with-argument=foobar=baz’, they get a correct
>> error
>>     message saying that “foobar” is not a known parameter.
> Interesting idea to piggy-back on the properties field, and it might
> save some code (at least initially), but I don't see the overlap here.
> None of the current properties (superseded, upstream-name, *-variant,
> cpe-name, hidden?) make much sense to expose in this way; they're
> semimmutable facts about the package.

Also, at present, the current 'properties' field can be changed without
changing the derivation, and I think that's quite useful.  It's nice to
be able to do things like increase the build timeouts on a core package,
for the sake of a slow architecture, without forcing rebuilds of
everything on top of that package on other architectures.

So, I would prefer to see a different package field used for this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]