[PATCH] gnu: linux-libre: add linux-libre-stable & linux-libre-longterm

  • Open
  • quality assurance status badge
Details
3 participants
  • Michael Ford
  • Leo Famulari
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Michael Ford
Severity
normal
M
M
Michael Ford wrote on 6 Nov 2023 14:26
(address . guix-patches@gnu.org)
CAFyhPjW_ouvj8+_Fph4Rp838dqW8Re8dBx-5yjit5DxD0b=AXA@mail.gmail.com
From dbe93718ea3dbae9d3e4795d0cea239cd3d6a674 Mon Sep 17 00:00:00 2001
From: fanquake <fanquake@gmail.com>
Date: Sun, 5 Nov 2023 18:31:55 +0000
Subject: [PATCH] gnu: linux-libre: add linux-libre-stable &
linux-libre-longterm

A project I'm involved with would find it convenient to have pointers to
the current stable / longterm kernel header branches, without having to
specify an exact version. This way, we can point to i.e the longterm
branch, and with each time-machine "bump", continue to have whatever the
current longerm branch happens to be. So I'm submitting this patch for
discussion / inclusion. Obviouly one overhead is remembering to keep
these variables in sync whenever the status of the longterm/stable
branches changes.

* gnu/packages/linux (linux-libre-stable): New variable.
(linux-libre-longerm): New variable.
---
gnu/packages/linux.scm | 2 ++
1 file changed, 2 insertions(+)

Toggle diff (17 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 95a66e3d6a..a50526734e 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -790,6 +790,8 @@ (define-public linux-libre-headers-5.15.49

"13zqdcm4664vh7g57sxbfrlpsxm7zrma72mxdfdz7d9yndy2gfv8"))

(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)



;;;
--
2.42.1
M
M
Maxim Cournoyer wrote on 13 Sep 16:36 +0200
(name . Michael Ford)(address . fanquake@gmail.com)
87wmjfwrhh.fsf@gmail.com
Hello,

Michael Ford <fanquake@gmail.com> writes:

Toggle quote (33 lines)
>>From dbe93718ea3dbae9d3e4795d0cea239cd3d6a674 Mon Sep 17 00:00:00 2001
> From: fanquake <fanquake@gmail.com>
> Date: Sun, 5 Nov 2023 18:31:55 +0000
> Subject: [PATCH] gnu: linux-libre: add linux-libre-stable &
> linux-libre-longterm
>
> A project I'm involved with would find it convenient to have pointers to
> the current stable / longterm kernel header branches, without having to
> specify an exact version. This way, we can point to i.e the longterm
> branch, and with each time-machine "bump", continue to have whatever the
> current longerm branch happens to be. So I'm submitting this patch for
> discussion / inclusion. Obviouly one overhead is remembering to keep
> these variables in sync whenever the status of the longterm/stable
> branches changes.
>
> * gnu/packages/linux (linux-libre-stable): New variable.
> (linux-libre-longerm): New variable.
> ---
> gnu/packages/linux.scm | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 95a66e3d6a..a50526734e 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -790,6 +790,8 @@ (define-public linux-libre-headers-5.15.49
>
> "13zqdcm4664vh7g57sxbfrlpsxm7zrma72mxdfdz7d9yndy2gfv8"))
>
> (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?

Reviewed-by: Maxim Cournoyer <maxim.cournoyer@gmail>

--
Thanks,
Maxim
L
L
Leo Famulari wrote on 13 Sep 17:50 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
ZuRfXlyQ3Av8y9IP@jasmine.lan
On Fri, Sep 13, 2024 at 11:36:10PM +0900, Maxim Cournoyer wrote:
Toggle quote (6 lines)
> > (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:


Should we add an alias for it?

We also have a package called 'linux-libre-lts', which is supposed to be
the most recent kernel with long-term support.

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.
M
M
Maxim Cournoyer wrote on 14 Sep 15:25 +0200
(name . Leo Famulari)(address . leo@famulari.name)
87y13us6yu.fsf@gmail.com
Hi Leo,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (14 lines)
> 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.

Toggle quote (3 lines)
> 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?

Toggle quote (3 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 66968@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66968
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch