Jason Chu wrote:
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 hear you! Cvsup it a overhead only, if you x86 guys had'nt set a password for eradonly anonymous not even bypassing a password prompt would have been necessary. ;-) Not to speak of the fact that Emz3 only runs on a platform where there is already a bootstrapped Emz3 compiler, which I haven't found for PPC yet. If it were possible I'd like to see everyone move away from it and use plain CVS or Subversion at best.
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.
I cannot agree more, all of the maintainers should always try to keep the PKGBUILDs exactly the same wherevere possible. Debian does it by the lowest deminor I think, stripping features off the configure until it works everywhere. Archlinux users might not agree with that, so do I. So smaller if[ $CARCH ] sections are totally ok. Unless some really obscure platforms such as ARM32, m68K or even SH-* are planned we won't have a problem. And even then, we could still have like a Archembedded or whatever.
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.
Do you mean for instance something like this? 2 kinds of tags in CVS for the latest stable: CURRENT-I686 CURRENT-PPC Then I do not see a problem with the fact that a new PKGBUILD might not yet be available for all platforms as soon as one platform's maintainer updated it. I think reviewing and kind of signing the package for other architectures is a must, not a problem in itself. If a user want's stuff that has not necessarily been tested or even been uploaded to be tested, he checks out the HEAD or whatever which always works for getting *all* the latest PKGBULDs, unlike TESTING-I686 on ppc f.e. - kth5