GNU bug report logs -
#66968
[PATCH] gnu: linux-libre: add linux-libre-stable & linux-libre-longterm
Previous Next
Full log
Message #14 received at 66968 <at> debbugs.gnu.org (full text, mbox):
Hi Leo,
Leo Famulari <leo <at> famulari.name> writes:
> On Fri, Sep 13, 2024 at 11:36:10PM +0900, Maxim Cournoyer wrote:
>> > (define-public linux-libre-headers linux-libre-headers-5.15.49)
>> > +(define-public linux-libre-stable linux-libre-headers-6.5)
>> > +(define-public linux-libre-longterm linux-libre-headers-6.1)
>>
>> Sounds like a reasonable thing to have. Leo, Wilko, what do you think?
>
> The package named 'linux-libre' is by definition the latest stable
> kernel:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm?id=22a34ea792ef0df15fd30d46f557b572c61d5404#n513
>
> Should we add an alias for it?
This wasn't requested... I guess the main use here is using older kernels.
> We also have a package called 'linux-libre-lts', which is supposed to be
> the most recent kernel with long-term support.
Michael, did you know about 'linux-libre-lts' ? It seems it would suite
your 'linux-libre-longterm' request well?
> I think the phrasing "longterm" is more idiomatic for Linux, so we could
> replace the -lts package with a -longterm package if people prefer that.
Sorry, I had forgotten we already had -lts. I guess we're already
covered then.
For the linux-libre-headers, I agree that the current situation is odd
at best; it should be renamed to linux-libre-headers/pinned or
something, since it's propagated by our build toolchain if I recall
correctly and entails a world rebuild.
linux-libre-headers could then point to the latest and greatest,
in sync with linux-libre.
Does that make sense? Renaming the package variable shouldn't cause any
rebuild.
--
Thanks,
Maxim
This bug report was last modified 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.