[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Custom kernel
Re: Custom kernel
Mon, 12 Dec 2016 23:44:34 +0100
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Mark H Weaver <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
>> 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
>>>> (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
>> 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
> 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
Yeah, I agree this is not ideal… just not *that* bad either. ;-)
Re: Custom kernel, Dmitri Anikin, 2016/12/05