Ticket #912 (new enhancement)
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: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.
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.