UBUNTU: [debian] Allow for package revisions condusive for branching
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> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Showing
Please register or sign in to comment