[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parameterized packages
From: |
Chris Marusich |
Subject: |
Re: Parameterized packages |
Date: |
Thu, 18 Jul 2019 22:41:55 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Mark H Weaver <address@hidden> writes:
>> Ludovic Courtès wrote:
>>> While thinking about <https://issues.guix.info/issue/35671> 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.z’, 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.
I agree with Mark; using a custom package field seems better here
because the arguments change the derivation (don't they?), but
properties do not. Maybe "argument-overrides"?
--
Chris
signature.asc
Description: PGP signature
- Re: Parameterized packages,
Chris Marusich <=