[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] RE: [M#73697383] Re: Disk-quota Request
From: |
Bill Page |
Subject: |
[Axiom-developer] RE: [M#73697383] Re: Disk-quota Request |
Date: |
Sat, 30 Sep 2006 22:10:10 -0400 |
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] RE: [M#73697383] Re: Disk-quota Request, (continued)
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Page, Bill, 2006/09/28
- [Axiom-developer] Re: [M#73697383] Re: Disk-quota Request, Ben Collins-Sussman, 2006/09/29
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Bill Page, 2006/09/29
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Gabriel Dos Reis, 2006/09/29
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Bill Page, 2006/09/30
- [Axiom-developer] Re: [M#73697383] Re: Disk-quota Request, Ben Collins-Sussman, 2006/09/30
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Bill Page, 2006/09/30
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Gabriel Dos Reis, 2006/09/30
- [Axiom-developer] Re: [M#73697383] Re: Disk-quota Request, root, 2006/09/30
- [Axiom-developer] Re: [M#73697383] Re: Disk-quota Request, Gabriel Dos Reis, 2006/09/30
- [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request,
Bill Page <=
- Re: [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Gabriel Dos Reis, 2006/09/30
- RE: [Axiom-developer] RE: [M#73697383] Re: Disk-quota Request, Bill Page, 2006/09/30
- [Axiom-developer] Re: [M#73697383] Re: Disk-quota Request, Alfredo Portes, 2006/09/29