Ticket #912 (new enhancement)

Opened 13 years ago

Last modified 11 years ago

Clean up and release build infrastructure (/mit/debathena/bin)

Reported by: geofft Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

Our build infrastructure from /mit/debathena/bin should be cleaned up and released, since they're useful in general for building packages for Debian/Ubuntu? releases.

Evan had some plans for cleaning up the UI, specifically along the lines of making "daupload" instead a subcommand of "da", automatically figuring out whether you need -A, etc.

Good places to announce this include Debian's debian-derivatives and Freedesktop's distributions lists.

Change History

comment:1 Changed 11 years ago by jdreed

As a slightly lower bar, we could consider packaging the build-server stuff, which really doesn't need to live anything other than the build server.

comment:2 follow-up: ↓ 3 Changed 11 years ago by jdreed

OK, here's my grand plan for debathena-build-server:

  • Update all the various utilities that currently use things like "dirname $0" to source a single shell file that sets sane defaults for all the variables, but allows overriding.
  • Include everything to make a build server, using c-p-d for when we modify things like pam's schroot config, etc.
  • Reduce duplication (e.g. simply require debathena-archive-keyring on the build server, rather than having two copies of the key)

This also means "build-all" will live on the build server, not in AFS. I don't see this as a problem. The stamps directory can still live in AFS, and locking is no worse than it is now. Once that's taken care of, we nuke /mit/debathena/bin/build-server, and that simplifies things a bit. The win here is that we actually have a real versioned understanding of what is where (there's a lot of skew between the locker and trunk/debathena/scripts, primarily because we have no dev->proposed->production workflow).

comment:3 in reply to: ↑ 2 Changed 11 years ago by kaduk

Replying to jdreed:

OK, here's my grand plan for debathena-build-server:

Seems generally reasonable

  • Reduce duplication (e.g. simply require debathena-archive-keyring on the build server, rather than having two copies of the key)

This introduces a potential slight bootstrapping problem but (1) I don't expect it to be a problem in practice and (2) it's not that hard to work around anyway.

comment:4 Changed 11 years ago by jdreed

While we're at it, /mit/debathena/bin was a svn checkout. It's now a git checkout. This is kind of dumb, because we deliberately have skew between the locker and git (in particular, the production installer is not in git). We should come up with a better solution, or actually package the stuff and come up with geofft's installer-a-deb-to-a-locker pony.

Note: See TracTickets for help on using tickets.