[Please reply to the debian-kernel list only.] We have a longstanding support problem where there is confusion between the kernel release string (utsname::release, output of uname -r, tail of package names) and the kernel package version.
Until recently, even uname -a would not report the package version for
the running kernel. You would have to look in /proc/version or the
kernel log. See bug #638878.
I dealt with this bug by changing the format of utsname::version
(output of uname -v) from:
"#" build-counter { " " flag }* " " date
to:
"#" build-counter { " " flag }* " Debian " package-version
(The date format being the default output format of the date command.)
However, two sysadmins have since complained that they find the date of
the current package easier to check than the package version string.
Certainly, there is more entropy in the date strings of stable package
updates than in their version strings.
The userland ABI sets a hard limit of 64 bytes (not including
terminating null) for this string. This is not sufficient to include
all the information in the old and new formats (otherwise I would not
have removed the date).
Here are examples of the old, new and possible alternative formats using
likely maximum-length components:
old: #1 SMP PREEMPT RT Tue Mar 21 23:12:08 GMT 2023 [46]
new: #1 SMP PREEMPT RT Debian 9.99~rc99-9~experimental.9 [51]
alt: #1 SMP PREEMPT RT 2023-02-21 Debian 9.99~rc99-9~experimental.9 [62]
alt: #1 SMP PREEMPT RT Debian 9.99~rc99-9~experimental.9 (2023-02-21) [64]
We could perhaps shorten 'experimental' to 'exp', which would leave
stable security updates with the longest version strings and allow for:
alt: #1 SMP PREEMPT RT Tue Mar 21 2023 Debian 9.99.99-9codename9 [59]
alt: #1 SMP PREEMPT RT Debian 9.99.99-9codename9 (Tue Mar 21 2023) [61]
Would anyone like to argue in favour of any particular alternative?
Ben.
--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
signature.asc
Description: This is a digitally signed message part
