Re: Custom kernel

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Hello!
>>
>> Mark H Weaver <address@hidden> skribis:
>>
>>> address@hidden (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.

I did see that :-), but there could have been a variable holding the
list of patches for 4.8; that would have significantly reduced
duplication.

> 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'.

Yeah, I agree this is not ideal… just not *that* bad either.  ;-)

Ludo’.