Hey Anil,
Oh I do hate this can of worms; it keeps getting opened/closed/re-opened.
--- explanation as it occurs to me at the moment, details may have
drifted with memory ---
There is a hack within Nexenta's dpkg to understand any version ubuntuN
= nexentaN even though this is wrong everywhere else. A long thread
exists on this (maybe a year or two ago?) and essentially states that
porting a package should s/ubuntu/nexenta/. Things get complicated with
upstream versions since we want a new upstream version to trump the
nexenta version:
take the original upstream version:
1.2.3ubuntu1-1
which produced the nexenta version:
1.2.3nexenta1-1
but should be trumped by the next upstream revision
1.2.3ubuntu1-2 (should be higher)
this works AFAIK. As a packager you need to be weary of incrementing a
version as is so tempting to do when patching an already in-repository
source. Patching the version to:
1.2.3nexenta1-2
would make it as new as the upstream version:
1.2.3ubuntu1-2
This means we can easily lose sight of little upstream patches.
A slightly better way to increment the version is to add another -N to
the end so that the version sequence would look like:
Orig:
1.2.3ubuntu1-1
Imported:
1.2.3nexenta1-1
Subsequent patches:
1.2.3nexenta1-1-1
1.2.3nexenta1-1-2
...
1.2.3nexenta1-1-N
This adds a lot of complexity to what a package maintainer must read up
on, understand and remember for every package. Keeping track of this
sort of thing seems error prone but would be as correct as you can get
with version substitution as we know it.
The next sticking point is that versions in debian/control should be
modified as well. Though things work as usual if you don't since the
nexenta = ubuntu hack in dpkg exists.
Another thing to keep in mind is the ordering of source repositories in
/etc/apt/sources.list when importing a source. You want the nexenta
repositories first and then the ubuntu repositories so that the nexenta
version that is the same as the ubuntu version is picked for download.
Why do we replace ubuntu with nexenta instead of appending nexenta1?
Great question, in theory this breaks some depends (when another package
depends on lt, le, or eq) so we don't do it. In practice I have no idea
how many depends this would actually break but I'm sure there would be
at least a couple of packages. (This topic can start me on a rant abut
not being able to increment internal versions anyway...)
--- /explanation ---
Alright, so anything ported over should be nexentaN instead of ubuntuN
but the autobuilder does not make that change. This was a tough choice
but the package that is imported by the ab is not modified in any
significant way as to be considered ported. In this fashion it seemed
to be wrong to consider the package as ported and so the source/binaries
are left with the ubuntu version attached. If/when the autobuilder makes
significant changes it should definitely change the version.
My personal opinion on the topic (for what that is worth) is that we
should append nexentaN when we make a significant change and fix
breakage elsewhere. It requires no special hacks in dpkg (or other
related/semi-related tools) and is a lot more transparent to everyone
involved (and those getting involved).
-Tim
Anil Gulecha wrote:
Hi,
This has come up a few times, so we should have a clear written policy
on how the version numbering changes from upstream into our
repository.
Lets take the following examples:
gtk-sharp2_2.12.0-2ubuntu3
zlib1g-1.2.3.3.dfsg-7ubuntu1
xyz-1.2.3.build2
The common practice is using apt-upstream-tool, which changes these as:
gtk-sharp2_2.12.0-2nexenta4
zlib1g-1.2.3.3.dfsg-7nexenta2
xyz-1.2.3.build2nexenta1
In some cases nexentaN is appended, in others [word]N is replaced with
nexentaN+1.
Autobuilder packages seem to keep the same version number.
We need a set of rules to fix these varied methods to something
consistent and logical. In certain cases, there are hardcoded version
rules in debian/control, ex: xyz ( 1.2.3ubuntu2) , which can fail
after version change to nexenta3.
A good plan seems to be to simply keep the upstream name, and add
nexenta1 , and increment for each of our revision. This keep things
like package versioning right (?).
Comments/suggestions on other ways to proceed?
Anil
___
gnusol-devel mailing list
gnusol-devel@lists.sonic.net
http://lists.sonic.net/mailman/listinfo/gnusol-devel
