[PATCH] UBUNTU: [Packaging] Allow for package revisions condusive for branching

[Dann Frazier]

On Tue, Aug 12, 2014 at 9:15 AM, Tim Gardner <tim.gardner at canonical.com> wrote:
> On 08/11/2014 01:50 PM, dann frazier wrote:
>> 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 at canonical.com>
>> ---
>>  debian/rules.d/0-common-vars.mk | 6 +++---
>>  debian/scripts/misc/getabis     | 2 +-
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/debian/rules.d/0-common-vars.mk b/debian/rules.d/0-common-vars.mk
>> index a0c62e9..629c12e 100644
>> --- a/debian/rules.d/0-common-vars.mk
>> +++ b/debian/rules.d/0-common-vars.mk
>> @@ -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
>> diff --git a/debian/scripts/misc/getabis b/debian/scripts/misc/getabis
>> index aa8ed7f..4349499 100755
>> --- a/debian/scripts/misc/getabis
>> +++ b/debian/scripts/misc/getabis
>> @@ -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
>>
>
> How about something a bit simpler, e.g., regular expressions that
> isolate the known fields. This will allow you to append any cruft you
> want as long as it starts with a non-numeric character.

The "+topic.X" appending isn't a big deal, that works today. The
bigger issue is the ABI fun, and I couldn't figure out a way to do
that without adding a new (optional) revision field. Unfortunately,
that parsing isn't supported with the simpler regexes:

My Parsing
-----------------
= abinum =
$ echo "33.59.58" | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/'
33.59
= uploadnum =
$ echo "33.59.58" | sed -r -e 's/[^\+]*\.([^\.]+(\+.*)?$)/\1/'
58

Your Parsing
-------------------
= abinum =
$ echo "33.59.58" | sed -e 's/^\([0-9]*\)\.\([0-9]*\).*/\1/g'
33
= uploadnum =
$ echo "33.59.58" | sed -e 's/^\([0-9]*\)\.\([0-9]*\).*/\2/g'
59

I guess the first question is - independent of the implementation, are
you +/- 1 with this new optional field? If you are, and the
complicated regex is the only concern, I can think of a few ways of
cleaning it up - specifically by trimming the "+.*" before we start
slicing up the x.(y.)?z.

 -dann

> rtg
> --
> Tim Gardner tim.gardner at canonical.com