[ale] To rpm or to tar.gz that is my question.

aaron aaron at pd.org
Wed Jul 25 09:47:37 EDT 2001


Previously, C I typed into the ether:
> Can you configure rpm's to install the package as
> easily as you can if you install from source.

Actually, I've found RPM's to be easier from the get go.
Making install simple, consistent and convenient are, after all,
what RPM and DEB packages are about.

> I enjoy installing from source, I know where things will wind
> up and apps seem to run better if installed from
> source.  I was wonder what other peoples opinion on
> this subject was.

I'll make an effort to install from tarball source if I have a calc
intensive or frequently used app that deserves optimizaton for my 686
(and there is no 586 or better RPM). Compiling to the processor and
system config can provide better performance, but I've not found the
gains significant enough to make the extra compiling efforts a
requisite.

Installing from tarball isn't a newbie op, either, and it does take
extra time, knowledge and attention. I find the unpack, compile and
install steps for tgz/tar.gz packages aren't too daunting, but then I'm
working from a lot of shell command experience and a moderate programing
background that includes a little C and C++ in the mix. There is still
a ton I would like to know about gcc flags and the configure utility
and such, but I'm tackling some other challenges and languages first.

Long story short, the RPM convenience and simplicity are my preference;
in fact they're part of the reason I use a RedHat based distros
(in fact, RedHat) on my desktops.

RPM's have made exploring the Linux domain and trying out interesting
applications and alternatives a lot less tedious (click "install"),
less dangerous (authentication, version, lib and component conflict
checks), easy to trace (click "querry"), easy to update (click
"upgrade") and, VERY importantly, easy to UNDO (click "uninstall").
Nice touches like the WebFind feature have saved me time and headaches
on a couple of occasions, too.

I know there are shortcomings to RPM's and the package and process
aren't perfect, but I think it works pretty well. My own knit picks
are with the GUI side of the RPM utility: I find the GUI's package
selection steps a little counter intuitive, the "search" facilities
need more flexibility and wildcard support and the overall stability of
the GUI could be improved. Of course, Linux is all about empowering the
user, so if the GUI get in my way I just run RPM from the command line.
:-)

peace
(after justice)
aaron
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.





More information about the Ale mailing list