[68] in athena10
Re: Athena 10 source packages
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jan 30 10:49:36 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Anders Kaseorg <andersk@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <1201703467.24076.71.camel@balanced-tree.mit.edu>
Content-Type: text/plain
Date: Wed, 30 Jan 2008 10:48:32 -0500
Message-Id: <1201708112.5833.4.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Wed, 2008-01-30 at 09:31 -0500, Anders Kaseorg wrote:
> 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.
I'll write up the transform script and make dasource invoke it for
athena/ directories, and kill off debathena-config-build once I have
everything working.
I'm pretty sure I remember using mkinstalldirs before automake even
existed but it's been a while. We can just phase that out and switch to
mkdir -p if it seems anachronistic today.
I don't want to start using aclocal because it's part of automake, and
pieces of automake can have subtle dependencies on each other. So the
transform script will be manually copying in the Athena aclocal.m4.
> 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."
Oh, that's really valuable; thanks for digging that up. We'll go with
non-native in that case.
