> PS. On a related issue. The more I think about the 'zips' > directory in the Axiom distribution the more I think it was a > ReallyStupid (tm) invention. Why take a source code tarball from > another project (gcl) and stick it into the Axiom repository?
I see your 'reasons' cache has expired again. Please refresh it from the mailing list history. :-) Axiom is NOT the only one to do this and there are prefectly valid reasons for doing so. Review your version of SVN if you don't believe me. They include Neon and APR. You believe that yum and apt-get work and that they work for every user. But consider all of the software that got installed because you needed a couple Perl packages. I believe the number was in the hundreds. I've run into the same issue trying to automatically install yum packages. I generally abort the update if it insists on installing a new version of glibc when all i wanted was to bring some utility up to date. And consider what happens when the average user tries to update the utility, the update insists on re-installing glibc, and the user does not have root access. Plus if you apt-get GCL you might get a version from stable, unstable, or testing. Yet GCL-2.6.8pre only works on some systems and GCL-2.6.8pre2 only works on others and there is no build-time way to distinguish them. Nor is there a tag so you can't pull from the CVS. I'm waiting to see how this issue is handled in build-improvements. Axiom build should 'just work'. Not, 'just work if you have yum', 'have root access', and 'are willing to install a hundred Perl scripts' or 'know which CVS tag will work with this axiom version'. Axiom can build on Red Flag Linux. As far as I know they don't have either yum or apt-get (or if they do I don't know the chinese incantation). Axiom is nearly working on the MAC. As far as I know there is no yum for the MAC. Axiom build should 'just work'. > If we really need a copy of gcl, why don't we just add it properly > into the repository as source code? Why do we work around the > capabilities of the source code control system by saving the > tarball and patches against it, having to apply these patches > during the build instead of just committing these patches to > Axiom's version of gcl in the repository? All of this stuff is > stored in the repository in a compressed manner anyway, right? The reason to use the GCL tarball with patches is that gradually the patches get accepted upstream. If we copied the source tree into Axiom we would be maintaining our own version which would eventually get out of sync. A source tarball with patches does not get out of sync since the patches are obvious. The fact that the repository is or is not compressed has nothing to do with the whole issue. Part of your frustration seems to be coming from SVN. I'm using SVN in work and it 'locks' the source tree, insists I run 'cleanup' (which NEVER works), and forces me to unwind changes, blow away my source tree, refetch the repository, re-apply my changes, and commit. It is tedious. The whole idea of 'locking' is broken. I also use SVN on Magnus, one of my other open source projects. The checkouts regularly fail. I have to do a checkout followed by at least a half-dozen 'updates' to get a good source tree. And then commit bombs and I'm forced to try to clean up the resulting mess using the same dance of 'back-out, blow-away, checkout, update, update, update, update, update, update, apply changes, commit and pray. Darcs is slow but it works. Arch is complex but has never failed. CVS is old but never fails. SVN is broken. Face it. It's not ready for prime time. The only hope we have is to host it ourselves so you can use the admin tools to recover. t _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
