So there's a number of issues I have overlooked. Not surprising with the amount of sleep I've gotten in the past 48 hours. I apologize to all for my relative inefficiency and general slowness of thought on account of that.
Two big points Jason has uncovered, which divulge how little I know about srcpac: 1) It needs an actual repo under the hood, complete with CVS and pacman-ability to resolve dependencies and tell when a package needs updating and, 2) It can already be run as a user other than root to build and not install.
I should now point out again that packages in unsupported are not currently in any CVS repository. We do not intend to change that anytime soon. It's not the intent to make unsupported another versioned repo, just a place to share PKGBUILD materials that's a little more structured and centralized than the forums or the old incoming directory.
I should also point out that cvsup can sync collections that aren't in CVS. This came somewhat as a surprise to me, but it turns out that cvsup will fall back to the rsync method for handling these kinds of collections, which is probably substantially more efficient than using a script to fetch all the PKGBUILD materials, thus minimizing wasted bandwidth.
So putting all this together, I conclude that Jason is right: srcpac is the wrong tool for the job. In fact, I conclude that he's so right that even if we were to add unsupported to abs and share its PKGBUILD materials as a cvsup collection, srcpac wouldn't immediately work with it, since there's no real repo behind unsupported.
This suggests to me that the easy middle ground to seek out is to share the unsupported PKGBUILD materials via cvsup but NOT as part of abs, and to put a simple tool in the aurtools package to fetch unsupported to a standard directory somewhere (like /var/unsupported). This would mean you couldn't use srcpac with it but you could at least fetch all the PKGBUILDs onto your system easily and efficiently, and then decide what to build and what not to build.
New thoughts?
- P
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
