edgy debian packages get version number from somewhere other than the One True Version Number

[zooko]

I suspect that they get it from DIST/debian/changelog.

[zooko]

So right now, Josh is apt-getting allmydata-tahoe v0.2.0b2-blahblahblah on feisty, so the feisty deb has the right version number. (This is important so that he knows what he's apt-getting is compatible with our new home grid.)

[zooko]

But, when I run "make deb-edgy" on my edgy system, it produces:

-rw-r--r--   1 zooko zooko 286332 May  1 22:28 ./allmydata-tahoe_0.0.1_all.deb
-rw-r--r--   1 zooko zooko 264264 May  1 22:28 ./python-foolscap_0.1.2+_all.deb

So it seems like deb-feisty is doing the right thing but deb-edgy isn't.

[warner]

I think there's a difference between the makefile target that a human might use to create a .deb (which only pays attention to the top-most entry in the debian/changelog file), and the makefile target that the buildbot uses to create a .deb (which modifies that changelog file before building, by adding a version string derived from src/allmydata/init.py).

This is a relatively deep issue.. the .debs created by the buildbot (or from any in-between-releases verison of the code) need to be distinct from each other. Some projects that use, say, SVN for this will create 1.2.3-rNNN releases, derived from the current SVN revision. For Darcs we don't get such a nice linear version number, so we use a timestamp to insure distinguishability (no two builds of distinct code look the same) and monotonicity (adding more code results in a build that looks "newer" than those with less code).

One approach is to require developers to modify the version string on every single commit (or have a post-hook that does that for us), effectively re-introducing a linear ordering to patches but (I suspect) causing a lot of deployment problems in the process. Another approach might be to have some sort of central registry that maps linear version numbers to darcs 'context' files (effectively putting a numbered tag on each commit, but maintained outside of darcs's awareness). Another might just be to let the buildbot maintain a long-lived counter, and add it to each version string. (this wouldn't be conveniently available to regular users, though).

[warner]

I just pushed a patch to create version strings by looking backwards through Darcs for the most recent release tag, then counting patches since that tag to get a "build number" and appending it. These version strings are then included in source code (where they are available as allmydata.version) and also passed to debchange to set the version of the debian package. The generated version.py file will also be included in a source tarball (if we were using buildbot to generate source tarballs, which we aren't), which is how non-Darcs trees should get their version information.

I think this will solve the problem: now all of the .deb-making buildbots are using sensible, monotonically-increasing version numbers..