[arch-ports] pacbuild status and design

[Jason Chu]

On Wed, Aug 31, 2005 at 11:58:24PM +0200, Alexander Baldeck wrote:
> 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.

Well, cvsup is just sort of a seperate daemon for sharing cvs trees.  I
understand that cactus (I believe that's who it was) wrote some patches for
abs to work with subversion.  I wrote something similar for the old TUR...
it's not hard technically, it's finding acceptance that's so difficult.

> >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.

Hehehe, Archembedded.

> >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

Yeah, basically.

> 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.

By doing this though, we lose one of the major benefits of having an
autobuilder (Debian's autobuilder works like this): package releases for
multiple architectures.  When a Debian maintainer releases a new i686
package, their buildd detects that it's not available for the other
architectures and queues it up to be built.  The benefit is that building
for the other architectures happens all the time, so there's less catchup
that needs doing.

If builds have to be verified first, they're already being built on the
developer's boxes for that architecture.  Ignoring the benefits of a clean
build system (even though they are nice benefits...), why not use the
developer's package instead of the autobuilt one?

Thing about getting the HEAD specifically, you're never sure if it's for
current or for testing.  At least the way we're using it.

Ok, what about this... there are a lot of technologies we'd benefit from
using (something other than cvsup, different PKGBUILD tree layout, etc).
What if we modelled something off the current arch practices, but
substituted our own technologies?

Say we wanted to use svn and lay the repo out differently, we distribute a
patched abs that can handle the newer layout and different technology.  As
long as someone keeps the i686 PKGBUILDs in sync with the ones in the
official cvs tree on a regular basis (should be scriptable), we'd get all
the benefits of the new technology and we might even be able to convince
the other developers to move over.

Doing something like this would be more work on the outset, but would
probably be very helpful in the long run (especially if the newer system
was adopted ;) ).

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/20050831/5747780f/attachment.pgp>