Linux-Libre-LTS

Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 347 bytes --]

Hello Guix!

I think it is good to have a package-variable "linux-libre-lts", as 
mentioned in the table at https://jxself.org/linux-libre/

This way, users don't have to remember and change the version numbers in 
their operating-system-configuration or package-manifest, whenever there 
is new LTS release.

Thoughts?

Regards,
RG.

[-- Attachment #1.1.2: OpenPGP_0x5F5816647F8BE551.asc --]
[-- Type: application/pgp-keys, Size: 675 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Linux-Libre-LTS

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Wed, Oct 28, 2020 at 11:32:08PM -0400, Raghav Gururajan wrote:
> Hello Guix!
> 
> I think it is good to have a package-variable "linux-libre-lts", as
> mentioned in the table at https://jxself.org/linux-libre/
> 
> This way, users don't have to remember and change the version numbers in
> their operating-system-configuration or package-manifest, whenever there is
> new LTS release.
> 
> Thoughts?
> 

I was waiting for the kernel code reorganization before adding it as a
variable. The trick is to add also linux-libre-lts-source and all the
others, and in a useful location. Now it's just taking the time to add
it in somewhere.

Do you want to take a stab at it? I'm not sure when I'll get around to
it.





-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux-Libre-LTS

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

Raghav!

Raghav Gururajan 写道：
> I think it is good to have a package-variable "linux-libre-lts", 
> as
> mentioned in the table at https://jxself.org/linux-libre/

It is!  Would you like to try your hand at a patch?  It should be 
easy if unexciting work.  (If you want excitment you can suggest 
making it the default.)

We should use upstream[0] release names, though, not roll our own 
(+less clear) ones.  So ‘-longterm’ instead of ‘-lts’.

Kind regards,

T G-R

[0]: https://www.kernel.org/category/releases.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Linux-Libre-LTS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On Thu, Oct 29, 2020 at 09:24:08AM +0100, Tobias Geerinckx-Rice wrote:
> Raghav!
> 
> Raghav Gururajan 写道：
> > I think it is good to have a package-variable "linux-libre-lts", as
> > mentioned in the table at https://jxself.org/linux-libre/
> 
> It is!  Would you like to try your hand at a patch?  It should be easy if
> unexciting work.  (If you want excitment you can suggest making it the
> default.)

Go for it!

> We should use upstream[0] release names, though, not roll our own (+less
> clear) ones.  So ‘-longterm’ instead of ‘-lts’.

+1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 387 bytes --]

Hi Efraim!

> I was waiting for the kernel code reorganization before adding it as a
> variable. The trick is to add also linux-libre-lts-source and all the
> others, and in a useful location. Now it's just taking the time to add
> it in somewhere.
> 
> Do you want to take a stab at it? I'm not sure when I'll get around to
> it.

Cool! I'll give it a shot.

Regards,
RG.

[-- Attachment #1.1.2: OpenPGP_0x5F5816647F8BE551.asc --]
[-- Type: application/pgp-keys, Size: 675 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 491 bytes --]

Hello Tobias!

> It is!  Would you like to try your hand at a patch?  It should be easy 
> if unexciting work.  (If you want excitment you can suggest making it 
> the default.)

Sure! Yeah, making it default was the next thing in my mind.

> We should use upstream[0] release names, though, not roll our own (+less 
> clear) ones.  So ‘-longterm’ instead of ‘-lts’.

By upstream you mean linux-libre or linux? The linux-libre uses the name 
'lts'.

Regards,
RG.

[-- Attachment #1.1.2: OpenPGP_0x5F5816647F8BE551.asc --]
[-- Type: application/pgp-keys, Size: 675 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Linux-Libre-LTS

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Hi Raghav,

Raghav Gururajan 写道：
> Sure! Yeah, making it default was the next thing in my mind.

Honestly no idea where I stand on that but I can bring the 
popcorn.

>> We should use upstream[0] release names, though, not roll our 
>> own
>> (+less clear) ones.  So ‘-longterm’ instead of ‘-lts’.
>
> By upstream you mean linux-libre or linux?

Linux.

Linux-Libre don't develop a kernel nor backport/provide any of 
said long-term ‘support’.  They're ‘upstream’ of us in a trivial 
way: we gratefully re-use their work.

> The linux-libre uses the name 'lts'.

Where?  It's neither here[0] nor there[1].  I found it on blogs.

The name isn't that important; just don't change it for fun, and 
‘longterm’ is what I'm used to hearing upstream.

Kind regards,

T G-R

[0]: https://www.fsfla.org/ikiwiki/selibre/linux-libre/
[1]: 
http://linux-libre.fsfla.org/pub/linux-libre/releases/5.4.74-gnu/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 377 bytes --]

Hey Tobias!

> Where?  It's neither here[0] nor there[1].  I found it on blogs.
> 
> The name isn't that important; just don't change it for fun, and 
> ‘longterm’ is what I'm used to hearing upstream.

Here, https://jxself.org/linux-libre/

There is a table at the bottom of the page. The same naming convention 
is used by Trisquel as well.

Regards,
RG.

[-- Attachment #1.1.2: OpenPGP_0x5F5816647F8BE551.asc --]
[-- Type: application/pgp-keys, Size: 675 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Linux-Libre-LTS

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Hi Raghav,

Raghav Gururajan 写道：
>> Where?  It's neither here[0] nor there[1].  I found it on 
>> blogs.
>> The name isn't that important; just don't change it for fun, 
>> and 
>> ‘longterm’ is what I'm used to hearing upstream.
>
> Here, https://jxself.org/linux-libre/

That's the blog I was talking about.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 560 bytes --]

Hello Efraim!

> I was waiting for the kernel code reorganization before adding it as a
> variable. The trick is to add also linux-libre-lts-source and all the
> others, and in a useful location. Now it's just taking the time to add
> it in somewhere.
> 
> Do you want to take a stab at it? I'm not sure when I'll get around to
> it.

Does the attached patch looks good?

The idea here is to update the version number that the variable
linux-libre-lts pointing to, whenever the new LTS version is released.

Regards,
RG.












[-- Attachment #1.1.2: 0001-gnu-Add-Linux-Libre-LTS.patch --]
[-- Type: text/x-patch, Size: 1500 bytes --]

From 883c805cf36a1b94fca45a3e3efbf851b7ea11ce Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Wed, 23 Dec 2020 22:43:10 -0500
Subject: [PATCH] gnu: Add Linux-Libre-LTS.

Enables the choice of using current LTS version of linux-libre in Guix System.

* gnu/packages/linux.scm (linux-libre-lts-version): New variable.
* gnu/packages/linux.scm (linux-libre-lts-pristine-source): New variable.
* gnu/packages/linux.scm (linux-libre-lts-source): New variable.
* gnu/packages/linux.scm (linux-libre-lts): New variable.
---
 gnu/packages/linux.scm | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 01f12f77d9..37727dcf94 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -931,6 +931,14 @@ It has been modified to remove all non-free binary blobs.")
                         ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t))
                       %default-extra-linux-options)))
 
+;; Linux-Libre-LTS means the *current* long-term support version of Linux-Libre.
+;; Reference: https://jxself.org/linux-libre/
+
+(define-public linux-libre-lts-version         linux-libre-5.10-version)
+(define-public linux-libre-lts-pristine-source linux-libre-5.10-pristine-source)
+(define-public linux-libre-lts-source          linux-libre-5.10-source)
+(define-public linux-libre-lts                 linux-libre-5.10)
+
 \f
 ;;;
 ;;; Specialized kernel variants.
-- 
2.17.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Linux-Libre-LTS

[Mark H Weaver]

Hi Raghav,

Raghav Gururajan <rg@raghavgururajan.name> writes:

> I think it is good to have a package-variable "linux-libre-lts", as 
> mentioned in the table at https://jxself.org/linux-libre/
>
> This way, users don't have to remember and change the version numbers in 
> their operating-system-configuration or package-manifest, whenever there 
> is new LTS release.
>
> Thoughts?

I have one concern.

It seems to me that the main reason to specify an LTS kernel is to avoid
the unscheduled breakage that can occur when updating to a new kernel
release series (i.e. to a new major+minor version).  Using
"linux-libre-lts" would fail to avoid these unscheduled updates; it
would merely reduce their frequency.

The only way to reliably avoid unscheduled major+minor kernel updates is
to specify "linux-libre-5.10" or similar.  The cost of this approach is
trivial: editing a few characters in the OS configuration when one
wishes to update to a newer LTS series.  The benefit is that the user
gains control over when these updates will happen, and thus when any
associated breakage will occur.

To my mind, the benefit of this approach is so compelling, and its cost
so trivial, that I can hardly understand why anyone who wishes to use an
LTS kernel would choose otherwise.

If we add "linux-libre-lts" to Guix, I worry that some users would use
it without understanding what they are sacrificing, and later get burned
by breakage when we modify its binding next year, or in some future
year.

A user who does not understand Guix in depth might reasonably expect
that when choosing "linux-libre-lts", upgrades to a later LTS series
would be postponed until the user gives explicit consent.  In theory,
Guix could be modified to behave this way, although I doubt it would be
worth the added complexity.  In any case, since it *could* be done, a
user might reasonably expect it.

If the goal is to solve the problem of users forgetting to update to
newer LTS kernels, I suggest exploring other approaches.  Perhaps we
could implement some system where Guix provides periodic reminders to
consider upgrading, when an older LTS kernel is specified in the OS
configuration and a newer LTS is available.  There'd need to be a way to
silence the warnings though.

What do you think?

      Regards,
        Mark

Re: Linux-Libre-LTS

[Jonathan Brielmaier]

On 24.12.20 11:15, Mark H Weaver wrote:
>> Thoughts?
>
> I have one concern.
>
> It seems to me that the main reason to specify an LTS kernel is to avoid
> the unscheduled breakage that can occur when updating to a new kernel
> release series (i.e. to a new major+minor version).  Using
> "linux-libre-lts" would fail to avoid these unscheduled updates; it
> would merely reduce their frequency.
>
> The only way to reliably avoid unscheduled major+minor kernel updates is
> to specify "linux-libre-5.10" or similar.  The cost of this approach is
> trivial: editing a few characters in the OS configuration when one
> wishes to update to a newer LTS series.  The benefit is that the user
> gains control over when these updates will happen, and thus when any
> associated breakage will occur.
>
> To my mind, the benefit of this approach is so compelling, and its cost
> so trivial, that I can hardly understand why anyone who wishes to use an
> LTS kernel would choose otherwise.

It sums up, the more systems you maintain the more sums up this trivial
work. Defining "linux-libre-lts" is the same we do for Icecat or
Icedove. Yes, there can be breakage when they got update from one ESR
branch to the newer one.

So there are reasons to use always the newest LTS/ESR software version...

So I support this addition.

Re: Linux-Libre-LTS

[Mark H Weaver]

Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> On 24.12.20 11:15, Mark H Weaver wrote:
>>> Thoughts?
>>
>> I have one concern.
>>
>> It seems to me that the main reason to specify an LTS kernel is to avoid
>> the unscheduled breakage that can occur when updating to a new kernel
>> release series (i.e. to a new major+minor version).  Using
>> "linux-libre-lts" would fail to avoid these unscheduled updates; it
>> would merely reduce their frequency.
>>
>> The only way to reliably avoid unscheduled major+minor kernel updates is
>> to specify "linux-libre-5.10" or similar.  The cost of this approach is
>> trivial: editing a few characters in the OS configuration when one
>> wishes to update to a newer LTS series.  The benefit is that the user
>> gains control over when these updates will happen, and thus when any
>> associated breakage will occur.
>>
>> To my mind, the benefit of this approach is so compelling, and its cost
>> so trivial, that I can hardly understand why anyone who wishes to use an
>> LTS kernel would choose otherwise.
>
> It sums up, the more systems you maintain the more sums up this trivial
> work. Defining "linux-libre-lts" is the same we do for Icecat or
> Icedove. Yes, there can be breakage when they got update from one ESR
> branch to the newer one.

Well, one key difference is that IceCat only supports one ESR branch at
a time, which essentially leaves the user with no choice about when to
upgrade to a new ESR branch (assuming they want security updates).  Even
upstream Mozilla only supports one ESR branch most of the time, except
for 3 months per ESR cycle when they briefly support two ESR branches.

The situation with LTS kernels is radically different, because each LTS
series is supported for about 5 years beyond when they are superceded by
a newer LTS, and therefore users have a 5-year window from which to
choose their preferred time to update.  Users of "linux-libre-5.10"
could update to the following LTS near the end of 2021, or they could
wait at late as 2026 if they prefer.

> So there are reasons to use always the newest LTS/ESR software version...

The thing is, if they can tolerate unscheduled breakage, then why are
they using an LTS kernel?  That's the part I don't quite understand.

> So I support this addition.

Okay.  If there are users who want the stability of LTS kernels, but
prefer to lose control over when the upgrades happen in order to save
themselves a few edits per year, then we can add the variable.  I don't
have a strong argument against the _existence_ of this variable.

However, I think we should add a comment near its definition, warning
that by using "linux-libre-lts" in their configuration, they will
effectively lose control over when the update to a new LTS series will
happen.  If, in the future, this variable is advertised in the manual,
that should include a warning as well.

Moreover, I would prefer for any relevant comments/documentation to
state that the recommended practice when using LTS kernels is to use a
variable like "linux-libre-5.10", and to explain the reasons why.

This is based on my expectation that Guix users who can tolerate
unscheduled breakage from kernel updates will probably just use our
default "linux-libre" kernel, and that users who would choose
"linux-libre-lts" are probably doing so because they wish to avoid being
caught off guard by unscheduled breakage.  Does that make sense?

What do you think?

      Thanks,
        Mark

Re: Linux-Libre-LTS

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On Wed, Dec 23, 2020 at 10:54:30PM -0500, Raghav Gururajan wrote:
> Hello Efraim!
> 
> > I was waiting for the kernel code reorganization before adding it as a
> > variable. The trick is to add also linux-libre-lts-source and all the
> > others, and in a useful location. Now it's just taking the time to add
> > it in somewhere.
> > 
> > Do you want to take a stab at it? I'm not sure when I'll get around to
> > it.
> 
> Does the attached patch looks good?

It looks good to me. guix package -A linux-libre-lts doesn't show it,
but guix build -e '(@ (gnu packages linux) linux-libre-lts)' does, so
it'll work for referencing it, which is what we want.

> The idea here is to update the version number that the variable
> linux-libre-lts pointing to, whenever the new LTS version is released.
> 
> Regards,
> RG.
> 

Thanks! Patch pushed.



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux-Libre-LTS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Thu, Dec 24, 2020 at 09:24:17PM -0500, Mark H Weaver wrote:
> What do you think?

I understand your concerns about the ambiguous meaning of an "LTS"
kernel in the context of Guix.

In order to make it more concrete, we could attempt to stay on the same
long-term support kernel series between Guix releases. It might not
always be possible or convenient, but it could make it more meaningful.
If the LTS kernel were to expire before a new Guix release, we would
have to decide what to do. We shouldn't start backporting fixes or
maintaining our own tree, in any case.

Regarding the comment above the new variables, I think that the longterm
support kernels are, by definition, "current". If they are not current,
then they are not supported. If the variables should point to the newest
kernel with longterm support, let's change the comment.

Something to note is that, much of the time, Guix *only* offers
long-term support kernels.

Also, the dates on <https://jxself.org/linux-libre/> appear to have
drifted out of sync with the upstream at
<https://www.kernel.org/category/releases.html>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux-Libre-LTS

[Bengt Richter]

Hi Mark, et al,

On +2020-12-24 21:24:17 -0500, Mark H Weaver wrote:
> Hi Jonathan,
> 
> Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:
> 
> > On 24.12.20 11:15, Mark H Weaver wrote:
> >>> Thoughts?
> >>
> >> I have one concern.
> >>
I have several :)
       1. Abuse of the english word "stable"
          ISTM the updating churn in internet-retrievable software 
	  is anything but "stable" and -- with exceptions -- as implemented
	  has pi**-poor quality control (which a complete transactional undo graph
	  does not solve by itself).
       2. The amount of breakage borders on arrogant disregard of users.
       3. The situation amounts to denial-of-service sabotage of FLOSS.
       
> >> It seems to me that the main reason to specify an LTS kernel is to avoid
> >> the unscheduled breakage that can occur when updating to a new kernel
> >> release series (i.e. to a new major+minor version).  Using
> >> "linux-libre-lts" would fail to avoid these unscheduled updates; it
> >> would merely reduce their frequency.
> >>
> >> The only way to reliably avoid unscheduled major+minor kernel updates is
> >> to specify "linux-libre-5.10" or similar.  The cost of this approach is
> >> trivial: editing a few characters in the OS configuration when one
> >> wishes to update to a newer LTS series.  The benefit is that the user
> >> gains control over when these updates will happen, and thus when any
> >> associated breakage will occur.
> >>

How about a .guix-ask-first profile that guix would check for symlinks
and .gitignore- or .robot-like files saying how to treat designated objects
and operations?

There could be room in the .guix-ask-first profile for hints and warnings
and CVE references and schedules for periodic TTS nagging and or popup
notices. With guile it's only limited by your imagination and time :)

Anybody remember motd? :)

I actually like being reminded of important updates, but I want control of
initiating them. Also, I want the option to have the full CRUD-list of
what will happen when I do initiate it.

I want control because I despise having my preferences reset without my consent :)

> >> To my mind, the benefit of this approach is so compelling, and its cost
> >> so trivial, that I can hardly understand why anyone who wishes to use an
> >> LTS kernel would choose otherwise.
> >

I agree, so WDYT? Can we have the best of both worlds by designing
a .guix-ask-first profile and associated guix mods ?

> > It sums up, the more systems you maintain the more sums up this trivial
> > work. Defining "linux-libre-lts" is the same we do for Icecat or
> > Icedove. Yes, there can be breakage when they got update from one ESR
> > branch to the newer one.
>

To me, that is a measure of the quality control done on the newer one,
and the installation system :)

> Well, one key difference is that IceCat only supports one ESR branch at
> a time, which essentially leaves the user with no choice about when to
> upgrade to a new ESR branch (assuming they want security updates).  Even
> upstream Mozilla only supports one ESR branch most of the time, except
> for 3 months per ESR cycle when they briefly support two ESR branches.
> 
> The situation with LTS kernels is radically different, because each LTS
> series is supported for about 5 years beyond when they are superceded by
> a newer LTS, and therefore users have a 5-year window from which to
> choose their preferred time to update.  Users of "linux-libre-5.10"
> could update to the following LTS near the end of 2021, or they could
> wait at late as 2026 if they prefer.
> 
> > So there are reasons to use always the newest LTS/ESR software version...
> 
> The thing is, if they can tolerate unscheduled breakage, then why are
> they using an LTS kernel?  That's the part I don't quite understand.
>

.guix-ask-first ? (Please excuse the nagging :)

> > So I support this addition.
> 
> Okay.  If there are users who want the stability of LTS kernels, but
> prefer to lose control over when the upgrades happen in order to save
> themselves a few edits per year, then we can add the variable.  I don't
> have a strong argument against the _existence_ of this variable.
>

And let .guix-ask-first govern how to use it? :)

> However, I think we should add a comment near its definition, warning
> that by using "linux-libre-lts" in their configuration, they will
> effectively lose control over when the update to a new LTS series will
> happen.  If, in the future, this variable is advertised in the manual,
> that should include a warning as well.
> 
> Moreover, I would prefer for any relevant comments/documentation to
> state that the recommended practice when using LTS kernels is to use a
> variable like "linux-libre-5.10", and to explain the reasons why.
>
I would like a .guix-ask-first profile with append-only installation default
for itself, and the rest defaulting to avoidance of breakage.

Another thing I would like is for .guix-ask-first to have access to
some kind of package score for trustability, reliability, and hackability.

I'm not sure how to define a scoring system, but I want it to tell me
the difference between enthusiastic hobby-hacking and professional quality.

But also about trusting motivations: there are pro saboteurs, and genius amateurs :)

I like the stackoverflow scoring of answers. I'd like something similar for packages.
 
> This is based on my expectation that Guix users who can tolerate
> unscheduled breakage from kernel updates will probably just use our
> default "linux-libre" kernel, and that users who would choose
> "linux-libre-lts" are probably doing so because they wish to avoid being
> caught off guard by unscheduled breakage.  Does that make sense?
> 
> What do you think?
>
See above :)

>       Thanks,
>         Mark
> 
-- 
Regards,
Bengt Richter

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1.1: Type: text/plain, Size: 2928 bytes --]

Hi Mark!

> 
> I have one concern.
> 
> It seems to me that the main reason to specify an LTS kernel is to avoid
> the unscheduled breakage that can occur when updating to a new kernel
> release series (i.e. to a new major+minor version).  Using
> "linux-libre-lts" would fail to avoid these unscheduled updates; it
> would merely reduce their frequency.
> 
> The only way to reliably avoid unscheduled major+minor kernel updates is
> to specify "linux-libre-5.10" or similar.  The cost of this approach is
> trivial: editing a few characters in the OS configuration when one
> wishes to update to a newer LTS series.  The benefit is that the user
> gains control over when these updates will happen, and thus when any
> associated breakage will occur.
> 
> To my mind, the benefit of this approach is so compelling, and its cost
> so trivial, that I can hardly understand why anyone who wishes to use an
> LTS kernel would choose otherwise.
> 
> If we add "linux-libre-lts" to Guix, I worry that some users would use
> it without understanding what they are sacrificing, and later get burned
> by breakage when we modify its binding next year, or in some future
> year.
> 
> A user who does not understand Guix in depth might reasonably expect
> that when choosing "linux-libre-lts", upgrades to a later LTS series
> would be postponed until the user gives explicit consent.  In theory,
> Guix could be modified to behave this way, although I doubt it would be
> worth the added complexity.  In any case, since it *could* be done, a
> user might reasonably expect it.
> 
> If the goal is to solve the problem of users forgetting to update to
> newer LTS kernels, I suggest exploring other approaches.  Perhaps we
> could implement some system where Guix provides periodic reminders to
> consider upgrading, when an older LTS kernel is specified in the OS
> configuration and a newer LTS is available.  There'd need to be a way to
> silence the warnings though.
> 
> What do you think?
I agree with the fact that the package variable in the form
`linux-libre-X.Y` will provide fine grain control, over the form
`linux-libre-lts`. But having the latter does not prevent the user from
using the former, in the config.scm.

Regardless, your concern is valid. The user might or might not know the
difference between these forms. For this, I think we add an explanation
in manual, somewhat like this:

```

linux-libre => Always points to the latest released version.

linux-libre-lts => Always points to the currently released LTS version.

linux-libre-X.Y => Only points to the specific major+minor released version.

```

Regarding the reminders, I think it makes things more complex. Yet we do
remind users like "The guix distribution is X days old. Please consider
updating via `guix pull`". The --news will show the newer linux-libre
version.

Regards,
RG.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Linux-Libre-LTS

[Leo Famulari]

On Sun, Dec 27, 2020 at 12:09:05PM -0500, Raghav Gururajan wrote:
> Regardless, your concern is valid. The user might or might not know the
> difference between these forms. For this, I think we add an explanation
> in manual, somewhat like this:
> 
> ```
> 
> linux-libre => Always points to the latest released version.
> 
> linux-libre-lts => Always points to the currently released LTS version.

This guideline, and the code comment in 'gnu/packages/linux.scm', don't
make sense to me.

All of the kernel packages offered by Guix right now are current LTS
kernels. Do you mean "Always points to the newest released LTS version?"

Re: Linux-Libre-LTS

[Jonathan Brielmaier]

On 29.10.20 04:32, Raghav Gururajan wrote:
[...]
> Thoughts?
A problem with the approach pushed is that it's not easy to spot
`linux-libre-lts`. As its only a variable and not a package: `guix show`
and `guix package -A` wont find it.

Re: Linux-Libre-LTS

[Raghav Gururajan]

Hi Mark!

> This guideline, and the code comment in 'gnu/packages/linux.scm', don't
> make sense to me.
> 
> All of the kernel packages offered by Guix right now are current LTS
> kernels. Do you mean "Always points to the newest released LTS version?"

Yours makes it more clear. So,

linux-libre => Always points to the latest released version.

linux-libre-lts => Always points to the newest released LTS version.

Regards,
RG.

Re: Linux-Libre-LTS

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

@Mark or @Leo

>> This guideline, and the code comment in 'gnu/packages/linux.scm', don't
>> make sense to me.
>>
>> All of the kernel packages offered by Guix right now are current LTS
>> kernels. Do you mean "Always points to the newest released LTS version?"
> 
> Yours makes it more clear. So,
> 
> linux-libre => Always points to the latest released version.
> 
> linux-libre-lts => Always points to the newest released LTS version.

I have attached a patch to update the comment in linux.scm. Could any of 
you push it please?

Regards,
RG.

[-- Attachment #2: 0011-gnu-Revise-comment-for-Linux-Libre-LTS.patch --]
[-- Type: text/x-patch, Size: 1037 bytes --]

From 24fc8ba6ea11a0d45ea8b240292bd56dc865ae52 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Wed, 30 Dec 2020 16:15:26 -0500
Subject: [PATCH 11/11] gnu: Revise comment for Linux-Libre-LTS.

* gnu/packages/linux.scm (linux-libre-lts): Modify comment.
---
 gnu/packages/linux.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 99ad2b421c..c63abcbbc0 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -931,7 +931,7 @@ It has been modified to remove all non-free binary blobs.")
                         ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t))
                       %default-extra-linux-options)))
 
-;; Linux-Libre-LTS means the *current* long-term support version of Linux-Libre.
+;; Linux-Libre-LTS points to the *newest* released long-term support version of Linux-Libre.
 ;; Reference: https://jxself.org/linux-libre/
 
 (define-public linux-libre-lts-version         linux-libre-5.10-version)
-- 
2.29.2

Re: Linux-Libre-LTS

[Leo Famulari]

On Wed, Dec 30, 2020 at 04:18:40PM -0500, Raghav Gururajan wrote:
> @Mark or @Leo
> 
> > > This guideline, and the code comment in 'gnu/packages/linux.scm', don't
> > > make sense to me.
> > > 
> > > All of the kernel packages offered by Guix right now are current LTS
> > > kernels. Do you mean "Always points to the newest released LTS version?"
> > 
> > Yours makes it more clear. So,
> > 
> > linux-libre => Always points to the latest released version.
> > 
> > linux-libre-lts => Always points to the newest released LTS version.
> 
> I have attached a patch to update the comment in linux.scm. Could any of you
> push it please?

Yes, I will push it with kernel updates in a few hours. 

Re: Linux-Libre-LTS

[Leo Famulari]

On Wed, Dec 30, 2020 at 04:18:40PM -0500, Raghav Gururajan wrote:
> From 24fc8ba6ea11a0d45ea8b240292bd56dc865ae52 Mon Sep 17 00:00:00 2001
> From: Raghav Gururajan <rg@raghavgururajan.name>
> Date: Wed, 30 Dec 2020 16:15:26 -0500
> Subject: [PATCH 11/11] gnu: Revise comment for Linux-Libre-LTS.
> 
> * gnu/packages/linux.scm (linux-libre-lts): Modify comment.

Pushed as dfcd1a876e8c5ded8a5ad67450deaed3a7be7475