[email protected] (Ludovic Courtès) writes:
> Mark H Weaver <[email protected]> skribis:
>
>> More generally, I think we need to give more thought to how to handle
>> 'replacement' fields when we inherit packages, in order to do the right
>> thing when the inherited package is grafted. One way is to override
>> (replacement #f). Another is to use the 'package/inherit' macro from
>> (guix packages), which applies the same overrides to the replacement.
>> I can't think of a case where it's proper to leave the 'replacement'
>> unchanged when inheriting a package.
>>
>> What do you think?
>
> First, we could mark the ‘replacement’ field as “innate”, which means it
> will never be inherited (like the ‘location’ field.) Like you, I can’t
> think of a situation where inheriting the replacement makes sense.
>
> Then ‘package/inherit’ seems to be doing the rest of the job correctly.
> The bad thing is that it’s easy to forget to use it. If we’re
> motivated, we could hack this feature (let’s call it “recursive
> inheritance”) right into (guix records).
>
> Thoughts?
I've considered this, but I see a problem: when creating the replacement
package itself, e.g. 'glibc-2.25-patched' on the 'master' branch, we
need to inherit from the original package and *discard* the replacement.
If we used 'package/inherit' there, it would lead to an infinite series
of replacements.
It still might make sense to hack 'package/inherit' into (guix records)
as the default behavior, but then we would need a separate mechanism for
creating replacements.
What do you think?
Mark
