Hi, Tobias Geerinckx-Rice <m...@tobias.gr> 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=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. Thanks, Mark
