[arch-ports] pacbuild status and design

[Jason Chu]

First I'll go over the basic design of pacbuild, then I'll highlight how
far I am, and then I'll explain the the problems I see so far.

My original goal with pacbuild was to write a program that would scan abs
for package discrepencies between different architecture's repos (well,
between i686 and everything else), build the new package for that
architecture, and stick it in the appropriate repo.

I broke the design into four pieces: peach, cherry, strawberry, and waka.

Peach is the web interface for package validation.

Cherry is the main build manager, it scans the abs repo, queues packages,
sends them to remote strawberry instances, sets them to be validated, and
adds them to the repo after validation.

Strawberry runs on each remote build machine.  It gets builds from cherry
and sends them to waka to be built.

Waka takes a source package (I can explain this later if needed), builds it
in a clean chroot, and spits out a binary package.

Currently cherry does everything up to the validation part and strawberry
and waka are complete.  Peach is still but a twinkle in my eye.

Now the fun part: problems.  I started pacbuild for i586.  It worked really
well, because packages are very rarely modified from i686 to i586.  There
was no real need for a cvsup tree and whatnot.

I also designed cherry to do too much.  I should probably make another one
or two daemons in there.  One, at least, to scan the repos and queue
packages.  That way cherry can just worry about managing all the remote
builds.  The other daemon would be for putting the packages back into the
repos.  The only reason I would develop this seperately is then we could
use it for i686 as well.

The way pacbuild was designed originally, it needed the
single-PKGBUILD-for-all-architectures method.  It depended on all PKGBUILDs
working for all architectures and tried to build them for all architectures
without those architecture developers even having looked at an update.
This way architecture developers become more of a manager than an active
maintainer.

The problem here is that each architecture's version of a package (if the
newer version isn't in the ppc repo, for example) isn't accessible in abs.
To do the abs thing for each individual architecture, we need to tag them
at the very least (have seperate repos at the most).  Tagging them pretty
much means they'd need someone looking at them.  It's possible that the
build script could tag all the ones that were verified, but developers
would still need to fix problems that showed up and tag those.

As far as I know, Debian does it with one source package for many
architectures.  They also have different source sharing methods (I don't
know exactly how they work).  Frugalware does it with multiple repos, I
believe.  Gentoo has people sign off on each package on each architecture,
but they sort of have to in gentoo...

Comments?

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20050824/fca85d7c/attachment.pgp>