On September 30, 2006 9:17 PM Tim Daly wrote: > Bill Page wrote: > > > 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.
I DO NOT know any other project that stores source code tarballs in their source code repository. Do you? I did not say that storing gcl source code in the Axiom repository was necessarily a ReallyBad(tm) thing - just storing it as a compressed zip file is ReallyBad. Whether Axiom should be distributing gcl as part of it's source code (as patches or en mass) is a separate issue. > > You believe that yum and apt-get work and that they work > for every user. No they don't work for every user - just 95% of them. The others either have a unique system of their own choosing or they have badly screwed something up somehow. > But consider all of the software that got installed because > you needed a couple Perl packages. I believe the number > was in the hundreds. Yes. But it worked. Scary stuff. > 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. You must be one of those in the 5% category. ;) > > 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. > That's just stupidity. No excuses. > Plus if you apt-get GCL you might get a version from stable, > unstable, or testing. ??? You do have to configure apt-get properyly for it to work properly. > 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. Different problem. 'pre' mean 'pre-release'. We are lucky that it runs at all. > 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. !!! Wait until gcl-2.6.8 is released, of course. Nobody should be distributing pre-release software except in highly experiement branches. > > Axiom build should 'just work'. > That's simply unrealistic. Linux should just work. Windows should just work ... Maple should just work. None of them do. > 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. > What *are* you talking about? What does yum or apt-get have to do with this? > 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. > All patches are obvious in a source code control system. What is the problem? > The fact that the repository is or is not compressed has nothing > to do with the whole issue. > The point is that storing a binary tarball containing source code in a source code control system defeats the purpose and makes it necessary to do things in a more complicated way. > > 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. > We had previously discussed this long before SVN was ever an issue. > 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. > But I agree about SVN. My experience with subversion is all negative. I have no idea why the "major projects" have chosen such a monster. But I guess it works for them and there are a *lot* of people actively developing it and using it. > Darcs is slow but it works. Darcs seems to get faster with each release. 1.0.7 works very well for me. It is continuing to be actively developed and maintained. > Arch is complex but has never failed. Arch fails on windows and has (mostly) been abandoned by it's original developers. > CVS is old but never fails. > It's too complex - like subversion and arch - and does less. > 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. > Yes, I am afraid so. :-( Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer