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

[Tim Gardner]

On 08/12/2014 11:23 AM, Dann Frazier wrote:
> 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
> 

Ah, I'm just being thick. So what you would really like is a minor ABI
field in your binary package names so that _if_ you make a local changes
that breaks ABI, the next official distro kernel package will supersede
yours.

Does debian/scripts/abi-check understand a 2 field ABI number ?

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