On Tue, 2012-06-05 at 20:25 +0100, Stuart Prescott wrote: > Thomas Goirand wrote: > > By the way, could kernel developers switch to the more standard system? > > Why isn't the kernel backport using 3.2.0-2~bpo60+2 as version number? > > You'll find that the kernel maintainers *are* using that version number > scheme: > > $ apt-cache policy linux-image-3.2.0-0.bpo.2-686-pae: > Installed: 3.2.18-1~bpo60+1 > Candidate: 3.2.18-1~bpo60+1 > Version table: > *** 3.2.18-1~bpo60+1 0 > 100 http://backports.debian.org/debian-backports/ squeeze- > backports/main i386 Packages > 100 /var/lib/dpkg/status > > Your lesson in Debian version string comparison, while correct, doesn't > actually answer the question asked. > > Kernel packages also carry information in their package name, which is what > the original poster was asking about. In particular, the maintainers have an > ABI string that helps track breakage of locally compiled out-of-tree > modules. > > http://wiki.debian.org/DebianKernelABIChanges > > So sid current has kernel packages with names like: > > linux-image-3.2.0-2-686-pae > > where "2" is the ABI number; this package has a version string of > "3.2.19-1". On the other hand, squeeze-backports kernel shown above has an > ABI of "0.bpo.2". I guess it's important to be able to identify backports > kernels easily and to track this as a backports ABI but yes, it does make > for a long and overly complex package name (not package version). The kernel ABI is potentially different in the backport due to use of a different compiler version. Previously the ABI version string would be <n>.bpo, where <n> was the ABI version used in testing/unstable. However, that sorts higher according to GRUB and the linux-version command, which was undesirable. Therefore I've been using 0.bpo.<n> instead. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
Attachment:
signature.asc
Description: This is a digitally signed message part