[5] in athena10
Re: Athena 10 and Debathena
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Nov 30 13:08:40 2007
From: Greg Hudson <ghudson@MIT.EDU>
To: Anders Kaseorg <andersk@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <1196421911.20326.48.camel@balanced-tree.mit.edu>
Content-Type: text/plain
Date: Fri, 30 Nov 2007 13:08:35 -0500
Message-Id: <1196446115.6082.25.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Fri, 2007-11-30 at 06:25 -0500, Anders Kaseorg wrote:
> 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.
Here there may be some pushback from ISDA culture, which is very keen on
standardizing tools, and is currently standardized on Subversion. So
this may be an ugly case where we have to choose between collaborating
and using the best tool for the job.
Happily, the vast majority of Athena 10 packages will be based on source
code we control.
> 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).
The few packages we have libtoolized to date turn out to be packages
which are included in Debian, so I can see how you wouldn't have run
into it. However, we also have libraries like libgms and liblarv which
will never be included in Debian and which *ought* to be libtoolized per
Debian package policy.
My understanding of the CDBS autoconf support is that it will only
replace existing autoconf goo; it won't create it from whole cloth. We
could certainly write our own debian/rules logic to copy in the stock
autotools files (although picking which automake version directory to
copy mkinstalldirs and install-sh from is a pain), but that results in a
lot of debian/rules boilerplate for every Athena package.
Sam suggested that CDBS could probably be amended to make it easier to
maintain source packages without their own autoconf goo, but that's not
going to help us if we are going to be buildable on Ubuntu releases
older than 8.04.
> ~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.
Interesting point.
Real-world Debian packages don't use version numbers like this. How do
they deal with release upgrades where one expects a lot of system
library upgrades? "Badly" is one possible answer, since Ubuntu release
upgrades are not known for their robustness.
