Future alioth archive layout and autobuilder
Hi,
after Arnd helped me yesterday resolving most problems and getting a
working debian-amd64 changeroot (thanks again) I dreamed up some ideas
for the alioth archive and autobuilder for amd64. I writing this down
before the dream fades so to speak. Consider this a sketch.
Archive Layout:
incoming/sarge - Upload dir for sarge, sources only.
incoming/sarge-i386 - Upload dir for sarge i386, sources only.
incoming/sid - Upload dir for sid, sources only.
incoming/sid-i386 - Upload dir for sid i386, sources only.
incoming/failed - Build failures from the autobuilder
dists/main/sarge/binary-i386 - Bare neccesseties to convert i386 to
amd64. Assume stable-i386 is installed,
contains kernel, libc, dpkg, apt
d/m/sarge/binary-amd64 - Known working base + build-essential
biarch system. Directly debootstrapable.
d/m/sarge/d-i/binary-amd64 - Debian-installer udebs
d/m/sarge/installer-amd64 - Installer images for cdrom, netboot and
a chroot.tar.gz
d/m/sarge/source - Sources for sarge packages.
d/m/sid/binary-amd64 - Unstable area, everything new goes there.
d/m/sid/d-i/binary-amd64 - Unstable Debian-Installer udebs
d/m/sid/installer-amd64 - Unstable installer images
d/m/sid/source - Sources for sid packages.
pool - Actual debs and source files.
doc - Readmes, Docs, FAQ
archive/dists/main/sarge-r? - Release snapshots of previous releases
version-skews.txt - Version differences between us and
debian sarge/sid
Goals for the archive:
(0. Updates docs. Mention the alioth archibe in the FAQ and mark other
repositories as deprecated. I spend quite some time trying them out
and failing due to missing depends.)
1. Something that works without glitches. That would be declared sarge
and sarge uploads would be deprecated after that. (Sarge-R1 release)
2. Get dists/main/sarge/binary-i386 into the sarge release. Maybe fork
and rename packages (apt -> apt-amd64, dpkg -> dpkg-amd64,...) and
create an amd64 metapackage (apt-get install amd64; reboot; apt-get
update; apt-get upgrade; -> amd64 biarch system).
3. Complete base and build-essential packages and anything they
Build-depend on. Aparently that includes xfree86 and mysql. Existing
32 Bit flavours of anything new prefered. (Sarge-R2 release)
4. Ask ftp-master to add us to the debian archive as /project/amd64 or
something disjunct form the ongoing sarge release.
5. Convert base, then build-essential and then Build-Depends to amd64
flavours. Toolchain packages not ment to be 64 bit excluded. Amd64 gcc
makes problems, right? (Sarge-R3,4,... releases)
6. Pressure ftp-master into adding us to the normal debian
archive. Sarge should be out of the way then and we can bug
maintainers to add biarch patches/fixes without disrupting the sarge
release.
7. Testing amd64 toolchain, maybe create an experimental section for
that.
Autobuilder:
There will be 4 autobuilders threads:
sarge - amd64 biarch with current sarge chroot
sarge i386 - linux32 emulation with current sarge chroot
sid - amd64 biarch with current sid chroot
sid i386 - linux32 emulation with current sid chroot
A cronjob will rsync /incoming every hour to my Opteron. Any dsc files
found in one of the subdirs gets queued to the respective autobuilder
thread. Upon failure the sources, build-tree and log is moved to the
incoming/failed directory. Upon success the files are moved into pool
and the archive metadata is updated. All packages build, even the i386
flavour, are used for binary-amd64 only.
Packages for d/m/sarge/binary-i386 will not be autobuild. The
directory should only contain a selected few packages. Once they are
installed (and the new kernel booted) apt-get/dselect would use
binary-amd64 and update to a more complete biarch system. Updates if
neccessary are inserted manually.
MfG
Goswin
PS: Replace sarge with testing or the next testing codename if that
makes you feel better. Opinions?
PPS: Get S390x patches added to the archive, maybe get an S390x
autobuilder along or the ride.
PPPS: Collect gpg keys from everyone and check signatures on source uploads at some point
Reply to: