[PATCH] UBUNTU: [Packaging] Allow for package revisions condusive for branching
Dann Frazier
dann.frazier at canonical.com
Wed Aug 13 01:52:25 UTC 2014
On Tue, Aug 12, 2014 at 12:53 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
> 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.
Dammit. Why couldn't I have said it that concisely?
> Does debian/scripts/abi-check understand a 2 field ABI number ?
abi-check just takes the old/new abi strings as positional arguments
from the kernel build and avoids having to parse things itself. Thank
$deity, because I left my perl book behind the kegerator in my dorm
room in '97. I've done builds that have both broken and retained the
ABI and abi-check has DTRT.
Here's a snippet from a recent build using a minor ABI:
Debug: abi-check-generic
install -d /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-33.58.58+ilp.1/arm64
sed -e 's/^\(.\+\)[[:space:]]\+\(.\+\)[[:space:]]\(.\+\)$/\3 \2 \1/' \
/build/buildd/linux-3.13.0/debian/build/build-generic/Module.symvers |
sort > /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-33.58.58+ilp.1/arm64/generic
II: Checking ABI for generic...
II: Different ABI's, running in no-fail mode
Reading symbols/modules to ignore...read 0 symbols/modules.
Reading new symbols (33.58)...read 14473 symbols.
Reading old symbols (33)...read 14473 symbols.
II: Checking for missing symbols in new ABI...found 0 missing symbols
II: Checking for new symbols in new ABI...found 0 new symbols
II: Checking for changes to ABI...
-dann
> rtg
> --
> Tim Gardner tim.gardner at canonical.com
More information about the kernel-team
mailing list