[64] in athena10
Re: Athena 10 source packages
daemon@ATHENA.MIT.EDU (Evan Broder)
Tue Jan 29 14:43:36 2008
Message-ID: <479F81D2.7050205@mit.edu>
Date: Tue, 29 Jan 2008 14:43:14 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
CC: athena10@mit.edu
In-Reply-To: <200801291914.m0TJEpGK030424@equal-rites.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
With regards to how MacAthena is packaging things, I am using the SVN
repository in AFS as my upstream source, and I have a script that builds
my own tarballs and puts them in /mit/macathena/dist/ (or
http://macathena.mit.edu/dist/), which is then used as the source for
most packages so that installing packages isn't reliant on having AFS
installed.
If aclocal.m4 is needed to build the package, I add that when I build
the tarball. At build time, I drop in config.guess and config.sub (these
are distributed with fink because lots of software doesn't include
versions that recognize Darwin). I also add mkinstalldirs and install-sh
from the automake-1.9 distribution. So I don't actually rely on you guys
doing the transformation step.
I also don't care about the debian directory. I was planning to manually
exclude it when I build the tarball, but I forgot and decided it wasn't
worth the trouble of breaking all the MD5 sums.
I guess, basically, do what you want - you probably would have to work
to break what I'm doing currently.
- Evan
Greg Hudson wrote:
> 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.)
>
>
