[Axiom-developer] RE: [M#73697383] Re: Disk-quota Request

[Bill Page]

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.