Ubuntu versioning in native packages

Emmet Hikory persia at ubuntu.com
Sat May 31 12:15:35 BST 2008


Luca Falavigna wrote:
> When applying Ubuntu changes to a Debian native package, we usually use
> packagename_Xubuntu1 versioning. For instance, sxid source package [1]
> has version 4.0.5 in Debian and 4.0.5ubuntu1 in Ubuntu.
>
> If a native package needs to be NMUed, Debian uses version-0.1 style.
> This happened [2] to sxid, now Debian has 4.0.5-0.1.
>
> When there is need to merge these packages, we can not directly
> upload them because Ubuntu version is higher than Debian NMU
> one and we receive a REJECT from Soyuz.
>
> Is there something we can do to avoid these cases?

    It has been previously suggested that Ubuntu always use a version
of the form X.Y-0.0ubuntuZ when uploading modified Debian-native
packages.  In discussion this was considered less than ideal because
1) it's extra work to remember to do it, 2) there aren't many native
packages and people can just watch them, and 3) the developer tools
complain when this format is used (as they complain for Debian NMUs
for native packages).

    There's no  way to fix it afterwards: in order to be able to take
advantage of an alternate versioning scheme for native packages, we'd
need to start using it before the NMUs, just in case.  Note that in
addition to causing Soyuz to REJECT a sync, this issue also prevents
the packages from appearing in MoM, multidistrotools, or anything else
checking comparative version numbers.

    The common workaround in the past has been to merge by
incrementing only the Z in X.YubuntuZ, and expecting that the person
doing so will know which version is being merged, so that the
appropriate action is taken in the event of another NMU.
Conveniently, multiple NMUs of native packages are a rare case, so
this has not often required significant oversight.

-- 
Emmet HIKORY



More information about the ubuntu-devel mailing list