[67] in athena10
Re: Athena 10 source packages
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Wed Jan 30 09:31:54 2008
From: Anders Kaseorg <andersk@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <200801291914.m0TJEpGK030424@equal-rites.mit.edu>
Content-Type: text/plain; charset=utf-8
Date: Wed, 30 Jan 2008 09:31:07 -0500
Message-Id: <1201703467.24076.71.camel@balanced-tree.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
On Tue, 2008-01-29 at 14:14 -0500, Greg Hudson wrote:
> 1. Is there a transformation step to add autoconf goo between a
> version control checkout and a source package?
I've been trying to come up with a solution that doesn't require this
autoconf goo in the source tree at all. This seems futile because
autoconf tries really hard to make sure you can't distribute a package
without everything that it would need to configure itself on ancient
non-GNU systems.
automake --add-missing will copy in install-sh, but then check that
you're using automake before installing mkinstalldirs (I get the
impression that Athena's use of mkinstalldirs outside an automake
context is nonstandard). aclocal will create aclocal.m4
from /usr/share/aclocal*, but this obviously requires installing the
Athena aclocal tests there (which should perhaps be done anyway?). As
you pointed out, CDBS doesn't want to install config.sub or config.guess
unless they already exist.
I did observe that putting
AC_CONFIG_AUX_DIR([/usr/share/automake])
into configure.in renders config.sub, config.guess, install-sh,
mkinstalldirs unnecessary (if you also use AM_PROG_MKDIR_P to get a
${mkdir_p} that replaces ${top_srcdir}/mkinstalldirs in Makefile.in),
but this seems like it can't possibly be a good idea.
Anyway, of the two remaining options, I think I was slightly happier
with a tarball transformation step over a new build dependency, but I
don't care that much anymore. This issue is a mess either way.
> 2. Are Athena 10 packages treated as "Debian-native"?
The debian-mentors FAQ has some fairly strong guidelines:
<http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native>
"You should only use a native Debian package when it is clear that the
package would only ever be of use in Debian."
"There are cases where upstream ships a tarball which already contains a
debian directory. This is undesirable, even if you're upstream yourself
or can commit there."
"There's no need to remove the debian directory from their revision
control system [...], but at the very least the directory shouldn't
appear in releases."
tabbott and I argued for a while about whether these guidelines apply to
packages that aren't part of Debian proper, whether some of the given
justifications are really valid, etc. It seems hard to come up with
good ideological arguments either way, and there are various practical
tradeoffs involved, but I'm not convinced that a bit of easily-automated
extra work is enough of a reason to ignore the guidelines. In general,
we've seen enormous improvements from the effort we spent making
Debathena packages conform to the "Debian way" as much as possible.
> 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.
Er, right, that was indeed a mistake.
Anders
