[4] in athena10
Re: Athena 10 and Debathena
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Fri Nov 30 06:29:53 2007
From: Anders Kaseorg <andersk@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <200711300752.lAU7qRIM014218@equal-rites.mit.edu>
Content-Type: text/plain; charset=utf-8
Date: Fri, 30 Nov 2007 06:25:11 -0500
Message-Id: <1196421911.20326.48.camel@balanced-tree.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Thanks for taking the time to work with us. Here are some of my initial
thoughts.
On Fri, 2007-11-30 at 02:52 -0500, Greg Hudson wrote:
> Debathena does not currently use a version control repository.
> They're not throwing away any information--the source packages contain
> the full history--but ISDA has a policy of keeping everything in
> Subversion repositories on svn.mit.edu. Debathena developers would
> get commit access to this repository as part of the collaboration.
Version control is certainly important. The reason we haven't yet set
up a VCS for Debathena packages is that I wanted to spend some time
figuring out how to do it right. I've had some bad experiences
maintaining Debian packages that were sort of haphazardly shoved into a
Subversion repository. You've clearly put thought into this issue; I'd
like to suggest another alternative for consideration.
As you observe, since Subversion lacks merging support, it is not
well-suited to maintaining packages that are not Debian-native. Instead
of giving up platform-independent sources by making everything
Debian-native, we could maintain packages with a more modern VCS--my
impression is that the Ubuntu folks are pushing Bazaar and the rest of
the world is slowly moving towards Git. If you have something like Git,
you can keep the upstream sources and packaged sources in two separate
branches (or even repositories), and freely merge patches between them.
I have some experience using Git for this kind of task and it certainly
has been much more pleasant than doing manual merges with Subversion.
A distributed VCS, of course, also has the advantage that people not
involved in the project can utilize the VCS in the same first-class way
that project members do. This is becoming easier with the new Vcs-*
dpkg control fields that link source packages to repositories.
<https://wiki.ubuntu.com/NoMoreSourcePackages> and
<https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl> are interesting
reading. It would also be worthwhile to learn how tools like
svn-buildpackage, git-buildpackage, and bzr-builddeb do things; I have
not yet done so.
> That way you could check out athena/bin/delete (or whatever), use dch
> -i directly from the checkout to edit the changelog after making a
> change, and build the package directly from the checkout (no need for
> a package build script like I wrote over the past couple of weeks).
This is convenient for quick testing on a development machine, although
it should be pointed out that our final packages are built inside clean
chroot environments managed by sbuild, to ensure that they are not
corrupted by customizations to the local environment and that build
dependencies are properly specified; hence build scripts are necessary
anyway. (Also, Debian frowns on having VCS metadata like CVS or .svn
directories included in source packages.)
> Athena source directories do not currently contain generated or stock
> autoconf goo (configure, config.sub, config.guess, mkinstalldirs,
> install-sh, ltmain.sh, libtool.m4) or the Athena aclocal.m4 file.
Some of this goo may turn out to be unnecessary. CDBS has an option to
generate configure by running autoconf at build time, and copy the
newest config.sub and config.guess from the autotools-dev package.
mkinstalldirs and install-sh come with the automake package. ltmain.sh
and libtool.m4 come with the libtool package (I'm not sure where these
are used, and we haven't bothered including them in the Debathena
tarballs). Parts of the Athena aclocal.m4 might be replaced by upstream
equivalents, such as ac_check_krb5.m4 in the libkrb5-dev package.
It does, however seem to be common practice to include this goo in
tarballs. Maybe this is just so they can be built without depending on
autoeverything. My understanding of this whole situation is not very
complete.
> Cosmetic issue: Debathena uses package version numbers like
> "9.4.0-0debathena1~ubuntu7.04" to indicate which Debian or Ubuntu
> release a binary package was built on, and stores all of the resulting
> packages in one repository. I like the idea of using much more terse
> package versions like "10.0.0" and creating separate repositories for
> each Debian or Ubuntu release. tabbott disagrees with me, and I may
> just lack the necessary background to know why having one repository
> is best.
I'll try to explain our rationale behind the parts of the version
number.
9.4.0
We chose our "upstream" version number based on the version of
the corresponding Athena source RPM, although the sources were
actually checked out from Athena CVS (which doesn't have much of
a version number). Moving forward however, I think it is unwise
to lock package versions to the Athena release they are part
of--there is no reason to update every package with every major
release (and indeed some of the existing Athena packages haven't
actually changed since as early as Athena 7 or 8). This is
especially true for packages that actually have different
upstream version numbers, like pine and nmh.
-0debathena1
A package released in Debian starts life at release -1. For a
package that has not been released in Debian, we use tag
-0debathena1 to avoid conflicting with a potential future Debian
release. Since it is unlikely that most Debathena packages will
actually be merged into Debian, this serves more as a semantic
cue that the package originates outside of Debian. The
debathena1 incremented on every change to the packaging that
uses the same upstream source. This is analagous to the Ubuntu
versioning convention that exists for the same reason.
~ubuntu7.04
If packages for different releases are assigned the same version
number, then not only can they not live in the same repository
(under the default pool structure), but APT will not
automatically upgrade them if the user upgrades to a later
release. The version numbers are designed to ensure that
upgrades from 9.4.0-0debathena1~ubuntu7.04 to
9.4.0-0debathena1~ubuntu7.10 work correctly, and also to ensure
that a version compiled manually by the user will be preferred
(dpkg considers ~ to be negative, thus
9.4.0-0debathena1~ubuntu7.04 < 9.4.0-0debathena1). This is
similar to the version tags used by Debian and Ubuntu security
updates and backports (emacs 22.1-0ubuntu4~feisty2), but
generalized to sort better.
Anders
