[63] in athena10
Athena 10 source packages
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jan 29 14:15:35 2008
Date: Tue, 29 Jan 2008 14:14:51 -0500
Message-Id: <200801291914.m0TJEpGK030424@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: athena10@MIT.EDU
We have two issues to settle before moving forward with Athena 10
development. I believe they are orthogonal.
1. Is there a transformation step to add autoconf goo between a
version control checkout and a source package?
2. Are Athena 10 packages treated as "Debian-native"?
The answer to one does not really imply an answer to the other. We
could have Debian-native source packages containing autoconf goo or
non-Debian-native packages without.
Transformation step
-------------------
Athena 9.4 and Debathena both have a transform operation applied to a
checkout before a source package is constructed. Athena 9.4 calls
this "do.sh dist"; Debathena calls this "athena-tarball". The purpose
of this step is to copy in the Athena aclocal.m4 and any necessary
autoconf boilerplate, and generate the configure file. (As a matter
of fiat, we do not want to check this stuff into version control;
putting generated or boilerplate files into version control reduces
the utility of the repository by adding a lot of garbage churn that
has to be filtered out when browsing.)
The advantage of these transformation steps is that the source package
is useful outside the context of the normal packaging tools. For
instance, the Macathena project currently has the option to grab an
Athena 9.4 SRPM or Debathena source package, extract the tarball
(which is easier with the Debian source package than with the SRPM),
and build it immediately with ./configure and make. If we do not have
a transform step, the Macathena project will have to create their own
transform using knowledge of how Athena sources are built.
The disadvantage is more machinery on our end. If I am Andrew wanting
to test a candidate change to getcluster, I can't just check out
athena/bin/getcluster, make the change, and run debuild; I have to
first run the transform step.
Based on prior discussions I had thought we had agreed not to have a
transform step. If I was mistaken, I can torch debathena-build-common
and make dasource invoke a transformation script which does basically
what Debathena's athena-tarball does.
Debian-native packages
----------------------
This issue is of much less practical importance.
From one perspective, all Athena 10 packages look like prime
candidates for being treated as Debian-native. The same people
maintain the sources and the packaging materials, so why have the
extra gook? We can get prettier version numbers, simpler source
packages, and simpler machinery by combining the sources and
packaging. Sure, the tarball in our source package would contain a
debian/ directory which is irrelevant to Macathena and similar
projects, but it doesn't hurt them.
From a second perspective, packaging of Athena 10 is intrinsically
different from development of the core sources. There should be an
"upstream" package which does not contain the debian/ directory, and
it should not change just because we tweaked something under debian/
to alter the packaging.
I subscribe to the first perspective, as does Sam based on verbal
conversations. However, I'm not so attached to it that I want to
roadblock Athena 10 development, and it's possible that I have missed
practical reasons attached to the second perspective.
(A minor side point of confusion: there are some current Debathena
packages like debathena-libnss-nonlocal which do not have a Debian
version component but *do* have an orig tarfile and a separate diff
for the debian/ directory. That doesn't seem completely kosher, but I
may be missing something.)
