GreyGeek wrote:
>
>The 'error' is in using tarballs in the 21st century. It's like still
>starting your car with a hand crank and spark adjust. It's been my
>observation that compiling tarballs was very reliable two or three years ago.
>I usually had an 80-90% success rate. Now, that rate is 10-20% because so
>many apps are depending on distro specific versions of libraries and when one
>tries to downgrade or upgrade to that specific version cascading
>dependencies and conflicts arise. At some point you throw up your hands
>and say forget it.
>
>Just as an indication of how weird it is getting... I was unable to install
>Subversion with MDK 9.2 specific rpms, but I was able to install RedHat rpms
>on my MDK 9.2 box (I needed to overcome only 6 conflicts which required a
>total of NINE RH rpms to resolve) and get Subversion running. But, as
>Fedora, MDK, SUSE, etc., continues down their paths the divergency between
>their libraries will make this cross-over less and less likely to succeed.
>
>
>
>>FYI, on NetBSD, the steps to build subversion, and all its
>>dependencies if you don't have them, from source, are:
>>
>>
>
>FYI, I don't run NetBSD and probably won't ever do so.
>
>GreyGeek
>
>
>
>
Sorry, but tarballs are still very important and useful. You just need
to know when to use packages and when to use tars.
I usually use packages for all the base and peripheral stuff in the OS,
but for the purpose that the server is actually for (web server,
database, svn, etc...) I will compile that software from tars. Normally
they need custom configuration anyway, and usually the OS packages are
not up to date with the recent tar releases, in almost all software.
I also was quite annoyed the first few times I tried to install svn - I
even gave up a few times. I have much experience using tars and
compiling, and I really had to work at it. Eventually, I figured it
out, and since then some other people have posted some nice step-by-step
instructions on how to do it on *nix. For things like Berkeley DB,
there's no reason you need to upgrade the system version of it, you can
install it in a private location.
I do agree that the install process could be simpler (like maybe
including the src to things like neon in the src tree, statically linked
binaries), but as far as svn holding back the World Domination of Linux,
that's just way off. svn is not a tool for end users. I'm sure there
are even many developers who get by without using any type of rcs. svn
is on the cutting edge, and as such, it's usually advanced users who are
going to use it, and are going to deal with it's install quirks.
As more and more people begin to use svn, they will figure out easier
ways to do things including install, and hopefully contribute them.
That's the wonder of open source!
--
Brian Mathis
http://directedge.com/b/
Received on Tue Mar 2 20:04:10 2004