[arch-ports] pacbuild status and design

[Alexander Baldeck]

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