From: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255
Date: Thu, 4 Feb 2021 21:19:33 +0100 [thread overview]
Message-ID: <1612468714@msgid.manchmal.in-ulm.de> (raw)
In-Reply-To: <b17b4c3b2e4b45f9b10206b276b7d831@AcuMS.aculab.com>
David Laight wrote...
> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
Hitting such version checks still might happen, though.
Also, any wrapping introduces a real risk package managers will see
version numbers running backwards and therefore will refrain from
installing an actually newer version.
For scripts/package/builddeb (I don't use that, though), you could work
around by setting an epoch, i.e. (untested)
-$sourcename ($packageversion) $distribution; urgency=low
+$sourcename (1:$packageversion) $distribution; urgency=low
but every packaging mechanism in-tree and outside should adopt such a
change, if even possible. Which is why this feels bad.
Possibly I am missing something: What's the reason to not use
EXTRAVERSION as back in the old 2.6.x.y days, so change to 4.4.255.1 and
so on? Well, unless there are still installations who treat 4.4.255 as
2.6.64.255.
Christoph
next prev parent reply other threads:[~2021-02-04 20:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 5:59 Kernel version numbers after 4.9.255 and 4.4.255 Jari Ruusu
2021-02-04 6:20 ` Greg Kroah-Hartman
2021-02-04 7:26 ` Jiri Slaby
2021-02-04 8:51 ` Greg Kroah-Hartman
2021-02-04 11:00 ` Jiri Slaby
2021-02-04 16:28 ` David Laight
2021-02-04 16:48 ` Greg Kroah-Hartman
2021-02-04 20:19 ` Christoph Biedl [this message]
2021-02-05 6:52 ` Greg KH
2021-02-05 17:31 ` Tony Battersby
2021-02-05 18:11 ` Mauro Carvalho Chehab
2021-02-06 7:20 ` Greg Kroah-Hartman
2021-02-06 9:24 ` Mauro Carvalho Chehab
2021-02-06 9:29 ` Greg Kroah-Hartman
2021-02-06 9:48 ` Mauro Carvalho Chehab
2021-02-06 10:18 ` Hans Verkuil
2021-02-06 11:18 ` Mauro Carvalho Chehab
2021-02-06 7:22 ` Greg Kroah-Hartman
2021-02-05 9:06 ` Pavel Machek
2021-02-05 9:33 ` Greg Kroah-Hartman
2021-02-05 18:44 ` Pavel Machek
2021-02-06 7:23 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1612468714@msgid.manchmal.in-ulm.de \
--to=linux-kernel.bfrz@manchmal.in-ulm.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).