On Tuesday 02 March 2004 18:46, subversion@millenix.mailshell.com wrote:
> GreyGeek wrote:
> > I have just competed two experiences installing svn, which I think is a
> > marvelous program.
> > <rant>
> > The first experience was installing it on my W2K workstation at work.
> > Download the binary, double click to install it, done.
> > Download the TortoiseSVN binary, double click to install it, done.
> > Total time from first download to having an operational svn: 5 minutes.
>
> An even easier experience is available on numerous Linux & BSD systems. In
> your specific case, Mandrake has urpmi on the command line and rpmdrake as
> a GUI, both part of the default distro.
Urpmi works well when the apps you want are accessible in a format that urpmi
understands. Mandrake's urpmi settings on its club mirrors are messed up.
If it weren't for the PLF configuration tool urpmi on Mandrake wouldn't work
at all.
> Debian has apt. Gentoo has portage. BSDs have ports. Mac OS X has fink (an
> adaptation of apt, AIUI). As I've learned from this thread, all of them can
> use pkgsrc. Fedora, the most recent addition to the bunch, has both apt and
> yum available, and OpenCarpet is widely used with it, making it even
> easier. SuSE, I'm sure, has something of the same. Hell, even SlackWare has
> started including a package/configuration management system!
>
> In all of these, you don't even need to go to the author's web site to
> download the application, as it is in the distributors' repositories.
Did you notice that I stated that I went to Mandrake Club and downloaded their
Subversion 1.0 package?
>
> Basically, there is no reason, in this day and age, to be manually
> downloading packages and chasing their dependencies.
I agree. That was the core of my rant.
> All of the distros have solved this problem.
Not quite, but they're working on it.
> You don't sound like you're looking for bleeding
> edge recent releases, so you have no reason to bother with the tarballs.
> Despite the fact that Subversion 1.0 is recent, one of the traditionally
> slowest-moving distros, Debian, already has it packaged and installable
> with the single command 'apt-get install subversion', from the official
> repositories.
Debian's package installer is best, but their stable release is 18 months
behind RH, SUSE and MDK. I had Debian on my machine about 30 minutes before
I decided it was too retrograde.
>
> > The second experience was on my MDK 9.2.1 box at home.
> > Download source.
> > ./configure gives an error which cannot be resolved without rewriting
> > configure.in. Not going that route.
> >
> > Go to Mandrake club and download Subversion-1.0 rpm.
> > It gives missing dependency error.
> > Download missing rpm. Installation gives a missing dependency error and
> > a conflict error.
> > Removing the conflict gives cascading conflict errors. Fix them.
> > Struggle missing dependencies and cascading conflicts through with SEVEN
> > MORE mdk Subversion rpms.
> > Attempt to create repository -- can't find svn _ra_ something....
> > Give up and restore system.
> >
> > Download 9 RedHat RPM files. Resolve several dependency and cascading
> > conflict errors, similar to the MDK rpms. BUT, this time svn works!
> > Total time: 7 or 8 hours, finishing at 1:30AM.
>
> You wasted those 7 or 8 hours. See above for the tools available to you.
No, I found out that urpmi didn't work on MDK.
> > Went looking for a Subversion GUI client. Tried them all but none would
> > install save for the Java version, called Supervision-0.1.jar. BUT, it
> > won't open the repository so none of the files in the project display.
> > Total time: several hours, ending in failure. I must use the CLI to run
> > Subversion.
>
> Don't know about any other distros, but Debian has the latest rapidsvn
> available, again just an apt-get away. And you could have found it just
> doing an 'apt-cache search svn'
Oh, I found RapidSVN, but it requested svn-0.37, and it wanted wxWindows
2.4.1, which conflicted with my Boa_constructor install. Which did I want to
break? Not Boa.
>
> > Summary:
> > For a guy who has been programming for thirty years, using Linux since
> > RH 5.0, and has compiled several kernels and countless programs, to run
> > into this kind of mess at a time when the Distros are beginning to
> > surpass Windows is total nonsense. The current paradigm for programs
> > that are not built with QT3 to run on KDE or GNOME is NOT WORKING folks!
>
> You made this mess yourself, if you're still working in the 'stone age' of
> tarballs and the 'bronze age' of unassisted .rpm's. Come join us in the
> iron age, I guess. :-)
My nick is GreyGeek, and my computer programming experience started on the
punch board of an IBM 402 Tabulator in 1960, but that doesn't mean I live in
the 19th century. I'd love to use urpmi, which is MDK's tool, but it seems
to have been broken between 9.2 and 9.2.1 Urpmf didn't, and urpmi.addmedia
wouldn't. Now you know why I moved over to SUSE 9.0 about four hours ago.
>
> > Linux is beginning to attract users who don't care bout accessing the
> > source, don't have time nor inclination to modify sources so a particular
> > program will run on their machine. They have work to do, they want to
> > install a program with a single click and have it work. Don't tell me
> > it can't be done. See my first experience.
>
> It can be done. See my first paragraphs.
Not quite there yet. The best solution would be one binary for all distros.
Period. That's the way NVIDIA is doing it, OpenOffice is doing it, etc...
Think of all the wasted man-hours with everyone re-inventing the wheel on each
distro for essentially the same thing.
>
> > Create a binary that HAS EVERYTHING it needs to run. Every library,
> > every driver, EVERYTHING. Who cares about how big it is. HD space is
> > cheap, and most serious folks run broadband connections. Bittorrent is
> > available for those who still dialup. Then install it in /opt and add
> > the path to the bash config script. No exceptions, not distro conflicts.
> > Finally, make sure it runs on a virgin machine that has none of the
> > build tools or libraries used to create the app.
>
> This means that it won't work with any other tools, like RapidSVN or
> TortoiseSVN, unless you want them to include their own version of the
> libraries, which means that they will not necessarily interoperate with
> other installations.
No, it doesn't mean that. It would mean that third pary apps would have an
installation target that is independent of the distro.
> The primary purpose of shared libraries, today, is not
> saving memory or disk space, but facilitating interoperability. The savings
> are just nice side-effects.
Sorry, but that's not what I learned when I was learning how to compile ELF
applications using gcc. Dynamic libraries were used to miminize precious
disk and memory space. Remember, 10 years ago a box with 8 or 16MB of RAM
and less than 1GB of HD space was common place. Memory and HDs were
expensive, so your app had to use existing shared libraries to minimize its
memory footprint and HD storage space. Your 'today' interpretation of
'interoperability' runs into trouble when libfoo.RH.so.1 adds features to
libfoo.RH.so.0 and hopefully doesn't mess with existing features. But, along
comes libfoo.mdk.so.1 which isn't quite compatible with libfoo.RH.so.1 or
deprecieates a feature that someapp.noarch thought would be in libfoo.XX.so.1
but it's not. This is just another form of DLL hell, but with *.so.*'s
instead.
But, Philip, this thread has gone on long enough....(and we arrived at its
conclusion without anyone calling anyone else a nazi! ;-)
GreyGeek
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 3 02:57:49 2004