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.