Re: 01/01: gnu: glibc/linux: Add patches for CVE-2017-1000366.

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> 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