[lug] There must be a better way

[Sean Reifschneider]

On Mon, Jan 21, 2002 at 11:20:04PM +0000, James Alan Brown wrote:
>RPM's from SuSE that wont work on Red Hat 
>for example because of diff file mods to 
>the standard tar source files.

That's horrible.  As the maintainer of the Python RPMs, I must say that
I work at trying to make sure that they work on all the distributions...
Mandrake, in the past, has been really bad about this as well, but I think
they've gotten a lot better more recently.

>a clean hard drive and install the base 
>linux system then un-tar each required 
>package and compile it up as you go?

I originally started using Linux with Slackware.  My main machine, after a
year or so, was in pretty bad shape as far as old versions of different
packages sticking around and sucking up disc space, installing new
versions, etc.

I switched to RedHat at the time specifically because it had a package
management system.  The first RedHat install I did, I used RPMs when they
were on the base CD, and built other things that I needed in /usr/local
from tar files.  I was reluctant to try out new packages because of the
cruft they would leave around after an install.  More importantly, I knew
that if I had to get things back up and functional after an upgrade, not
knowing which of the packages that left files under /usr/local I really
needed, etc...

After that, I became a snob and would only install packages that had RPMs
available.  That way I can try it and delete it if I don't like it,
upgrades and the like are made much easier, etc...  You know what files
are associated with a particular package and vice-versa.

I had this 5.2 box that I didn't want to go through the pain of doing a
fresh install, but did want newer gtk and stuff on it.  I ended up with a
system on which no binary RPMs would work -- it had an older libc, so I
couldn't use 6.2 packages, but an newer gtk, so 5.2 packages wouldn't work.

The slavation there was Source RPMs.  Source RPMs are little more than a
shell script which includes the steps you need to take to turn the pristine
source into the binary and install the files...  Using an SRPM, I was
essentially building from source, a system which exactly matched the
libraries I had on my system.  Better, it allowed me to do *EXACTLY* the
same thing (compiling and configuring with the exact same options I used
last time, etc) if I had to do it in the future.

So, if I don't find an RPM, I'll often make my own.  It requires a bit more
work up front to get going, but it contributes something back to the
community, and when a new version comes out I often can just download the
new source, change the version number in the spec file, and build the new
version.  In the bargain, I also don't lose any special options I may have
compiled the previous version with.

So, I'd *HIGHLY* recommend you use some sort of packaging system.  It
really does make life a *LOT* easier...

I will agree that SuSE does some unusual stuff with their RPMs.  Like
including UUCP in the sendmail RPM?  I'm obviously most familiar with
fairly close RedHat derivitives, and I must say that I'm pretty happy with
them as far as using RPMs and SRPMs.  I can honestly say that the time
saved using other people's packages has more than paid for the time I've
spent developing RPMs for packages that don't have them.

Sean
-- 
 These go to eleven.
                 -- _This_is_Spinal_Tap_
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python