apache 1.3.26?

[Graham Leggett]

Christopher Murtagh wrote:

> There are *many* more benefits
> from doing this than any you would get with an RPM.

To be honest I don't agree with this, mainly because of a single 
showstopper: Six months from now, when someone else takes over the 
system, they have to spend ages figuring out "your" special server 
layout. No matter how good they are, there is a good chance a mistake 
will be made, and something will break - which is not acceptable.

>  When you use RPMs you get the following:
> 
>  1) Something else that keeps track of your packages for you.

Exactly. Someone else makes sure the files are tracked. Someone else has 
ensured this combination of packages works. Someone else has built a 
whole lot of support tools that fit in with the package. And when a 
third person has to come in and manage this, they're likely to be 
familiar with the layout already.

>  When you compile from source you get the following:
> 
>  1) Faster patches/fixes and this case is a perfect example. There are
> people on this list looking for a good RPM, when it took me less than 1/2
> hour to patch and recompile for 7 production servers.

A patched RPM was available from Redhat within hours. If this is too 
slow, just patch the SRPM yourself. RPM also gives you the source.

>  2) You get the software configured the way *you* want/need.

Which is exactly the problem. In 95% of cases the RPM solves the problem 
at hand. Doing it "your way" solves the exact same problem, but in some 
custom system. It's not maintainable, or futureproof.

>  3) You can modify the code should you need to.

You should not need to modify the code. If you do need to, make the 
change and submit it to the project for inclusion in the main project. 
Systems are not maintainable otherwise.

> An example: We couldn't
> use HtDig out of the box for our needs, but it took about 20 minutes of
> looking through the code and a simple change so that it would work with
> our system. You can't do this with an RPM.

You can do it with an SRPM.

>  4) Something better that keeps track of your packages -- you!

This is rubbish. Seriously, there is no way in hell I'm going to 
remember how I configured something six months ago, and in the majority 
of cases I'm not likely to configure it better than the RPM did in the 
first place. And when the next admin comes along, you're stuffed.

>  If you are telling people to only use RPMs, they're restricted to Beer,
> which, as many of us know, can lead to headaches like this.

For some reason most detractors of RPM forget to mention that you are 
free to compile an RPM from source.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm 
	"There's a moon
					over Bourbon Street
						tonight..."