[52] in athena10
Re: Athena 10 project infrastructure status
daemon@ATHENA.MIT.EDU (Tim Abbott)
Thu Jan 24 17:31:21 2008
Date: Thu, 24 Jan 2008 17:30:38 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <200801231926.m0NJQ47K010216@equal-rites.mit.edu>
Message-ID: <Pine.LNX.4.64L.0801231648290.24893@phoenix.csail.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 23 Jan 2008, Greg Hudson wrote:
> The build area issues are:
>
> 1. The imported debian control files list tabbott or andersk as
> maintainer. debuild -S looks for a key for the listed
> maintainer, which I obviously don't have, and blows out when it
> doesn't find one.
Anders are I are listed as maintainers only for those packages in the
packages/debathena/ subdirectory. Everything else (etc.) has
"Debian-Athena Project <debathena@mit.edu>" as the maintainer (and
probably the debathena/ things should also list debathena@ as the
maintainer). We use effectively "debuild -sa -us -uc" instead of
"debuild"; you can makes debuild default to this, by putting
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-sa -us -uc"
in ~/.devscripts.
I think there's also a convenient way to sign source packages as someone
other than the mainatainer (in Debian they call these "non-maintainer
uploads").
> 2. debuild -S does not like seeing Debian version numbers without an
> orig tarfile or directory. (This gets back to "I want Athena 10
> packages to be treated as Debian-native" vs. "existing Debathena
> packages aren't".)
>
> My first thought is to change all of the maintainer fields to
> release-team@mit.edu and create a corresponding private key which
> would be available to the developers, and to bump all of the version
> numbers to not include a Debathena component. (Also requires a change
> to dadch.) I'm a little concerned about how those changes might
> affect the relationship of Athena 10 development to production
> Debathena, so I wanted to bring up the issue for discussion here
> first.
Changing the contact email on the packages to a list not containing Anders
and I would result in the world having to maintain versions of the package
sources with two different contact addresses, which would be annoying.
In the long run, we'll probably have to do this, so that people contact
the right support source, but we could do something clever using the same
mechanism we use to add ~debian4.0 to version numbers to change the
contact address depending whether it's being built for the IS&T-supported
Athena platform or one of the SIPB-supported platforms. Before the Athena
10 release, it might be easiest to just use debathena@ for all packages,
since that contains ghudson as well as us.
> I could have my build area script create dummy orig tarfiles to make
> debuild happy. However, this would be a bit of a lie unless I
> arranged for the orig tarfile to be the same across changes to the
> debathena version component.
If one were to increment the orig version precisely when one changed the
package outside the "debian/" subdirectory, the orig tarball obtained via
"tar --exclude=debian" would be a valid orig tarball that's always the
same.
Given that it seems MacAthena will be probably be using the orig versions
as their upstream, there may be advantages to having a well-defined
non-Debianized version of the sources.
-Tim Abbott
