Re: [RFC] Putting the date back into utsname::version

2013-03-22 Thread Ben Hutchings
On Fri, 2013-03-22 at 11:30 +0100, Bastian Blank wrote: > On Fri, Mar 22, 2013 at 12:34:28AM +, Ben Hutchings wrote: > > 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] > > This increases

Re: [RFC] Putting the date back into utsname::version

2013-03-22 Thread Bastian Blank
On Fri, Mar 22, 2013 at 12:34:28AM +, Ben Hutchings wrote: > 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] This increases the distance between two versions to maybe 2 or 3 bytes. > Would

Re: [RFC] Putting the date back into utsname::version

2013-03-21 Thread Timo Juhani Lindfors
Ben Hutchings writes: > 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. Agreed. > Would anyone like to argue in favour of any particular alternative

[RFC] Putting the date back into utsname::version

2013-03-21 Thread Ben Hutchings
[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