@@ -61,11 +61,11 @@ ifeq ($(full_build),false)
skipdbg=true
endif
-abinum := $(shell echo $(revision) | sed -e 's/\..*//')$(abi_suffix)
-prev_abinum := $(shell echo $(prev_revision) | sed -e 's/\..*//')$(abi_suffix)
+abinum := $(shell echo $(revision) | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$$/\1/')$(abi_suffix)
+prev_abinum := $(shell echo $(prev_revision) | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$$/\1/')$(abi_suffix)
abi_release := $(release)-$(abinum)
-uploadnum := $(shell echo $(revision) | sed -e 's/.*\.//')
+uploadnum := $(shell echo $(revision) | sed -r -e 's/[^\+]*\.([^\.]+(\+.*)?$$)/\1/')
ifneq ($(full_build),false)
uploadnum := $(uploadnum)-Ubuntu
endif
@@ -11,7 +11,7 @@ fi
ver=$1
revision=$2
-abi=$(echo $revision | gawk -F. '{print $1}')
+abi=$(echo $revision | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/')
verabi=$ver-$abi
verfull=$ver-$revision
TLDR; This changes the way that version strings are parsed in the packaging to make it easier for me to maintain topic branches/PPA builds. There should be no changes to how things work today for standard Ubuntu kernels. But, it allows for topic-branch maintainers to add an optional ".X" in the ABI name, for reasons described below. <Regression Testing> ------------------ Old Parsing: = abinum = $ echo "33.58" | sed -e 's/\..*//' 33 = uploadnum = $ echo "33.58" | sed -e 's/.*\.//' 58 = abi = $ echo "33.58" | gawk -F. '{print $1}' 33 New Parsing: = abinum = $ echo "33.58" | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/' 33 = uploadnum = $ echo "33.58" | sed -r -e 's/[^\+]*\.([^\.]+(\+.*)?$$)/\1/' 58 = abi = $ echo "33.58" | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/' 33 </Regression Testing> When maintaining topic customizations that track Ubuntu kernel releases, it is nice have the following features: 1) Ability to decipher the base Ubuntu kernel revision used from the topic kernel's revision number 2) Use a version that dpkg sorts > the base Ubuntu version 3) Use a version that dpkg sorts < the next expected Ubuntu version 4) Ability to retains the same ABI as the base Ubuntu version when the ABI has indeed not changed. This helps with e.g. d-i compatibility. 5) Make use of ABI tracking facilities (vs. just disabling them) This is difficult to do with the current version scheme, which encodes the ABI number in the version string: <upstream-version>-<abi>.<rev> I can tack a "+topic.<N>" to the end of rev, we can solve 1-3, but only as long as as the ABI is the same. Once the ABI changes, I don't have a good way to bump it. If I increment the ABI, we'll overlap with the next Ubuntu ABI (breaking #4). If we jump to a huge ABI number (e.g. x100 to go from 32 to 3200), we'll have a package revision that will never again upgrade to an Ubuntu version (breaking #3), and never get back to the Ubuntu ABI (again breaking #4). I can of course use a linux-meta package to e.g. transition from a 3200 ABI back to a 32 ABI at the packaging level, but the bootloader will still consider 3200 to be newer and therefore the default. I've therefore started using the following scheme: <upstream-version>-<abi>(.topicabi)?.<rev>(+<topic>.<topicrev>)? Where topicabi must always be >= <rev> (ugly, but necessary). If I don't break the ABI, I can then branch and return like so: 3.16.0-8.6 -------------------------------------------------> 3.16.0-8.7 \ ^ \ | \--> 3.16.0-8.6+topic.1 -------> 3.16.0-8.6+topic.2 --------/ If I do need to break the ABI, I can branch and return like so: 3.16.0-8.6 -------------------------------------------------> 3.16.0-9.1 \ ^ \ ABI break #1 ABI break #2 | \--> 3.16.0-8.6.6+topic.1 -------> 3.16.0-8.7.6+topic.2 ----/ Signed-off-by: dann frazier <dann.frazier@canonical.com> --- debian/rules.d/0-common-vars.mk | 6 +++--- debian/scripts/misc/getabis | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)