Re: Custom kernel

[Mark H Weaver <mhw@netris.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Currently ‘make-linux-libre’ is not public, but we could probably make
>>> it public (David, WDYT?).  In the meantime, in your own module, you can
>>> do:
>>>
>>>   (define make-linux-libre
>>>     ;; It’s private but I wanna use it anyway!
>>>     (@@ (gnu packages linux) make-linux-libre))
>>
>> I think we should avoid exporting 'make-linux-libre' in its current
>> form.
>
> Makes sense.
>
>> Although it was an improvement in some ways over what we had
>> previously, I've found it to be an inadequate interface in many
>> respects, and in my opinion it needs to be redesigned.  I don't have
>> time to make a case now, but in practice it leads to redundancy.  For
>> example, when I recently added security fixes to linux-libre, I needed
>> to add the patches in two separate places, and every time I update the
>> version, I need to update two places as well.
>
> Looking at 6b2921c3acf2cc808128af97784929365f8582af, it seems that
> patches lead to modifications in only one place (the ‘make-linux-libre’
> call site), no?

If you look more carefully at 6b2921c3acf2cc808128af97784929365f8582af,
you'll see that I had to apply the patches in two places, and if we had
more kernel variants for other machines, it would have been more than
two places.

The problem is that there are multiple 'make-linux-libre' call sites for
the same kernel version, and each of them needs to be passed various
subfields of the 'source'.

There's no straightforward way to 'inherit' from a master 'linux-libre'
package and then override some of those parameters that are passed to
'make-linux-libre'.

       Mark