[TriLUG] Deb vs. RPM (was Icecast.conf and debian)

Tanner Lovelace lovelace at wayfarer.org
Wed Oct 17 01:05:38 EDT 2001


Haim Dimermanas wrote:


> That's when you start documenting what you do. You do have your system
> documented don't you?


Absolutely. :-)  But, I make use of what rpm records
for me to make that job a *lot* easier.

 
> My setup is very standard and quite complex. Again, documentation.


The patch files that get saved with the .src.rpm are very
useful for this, as are changelog entries.


> I agree with you on the utility of a package management system. I started
> using Linux with Slackware back in 96. After spending my entire days on
> freshmeat I realized that I needed a package management system. I looked at
> Red Hat and their rpm, it was awesome! I looked at debian, it was different.
> 
> I won't advocate Debian in this thread. I wrote something that I invite you
> to read:
> 
> http://dudle.linuxroot.org/docs/debian-install/debian-install-1.html
> 
> I explain why I chose to use Debian.


Like I said, I don't know Debian so I can't advocate it one way or
the other.  I do know RPM, though, and I pesonally like it quite a bit
(or hadn't you noticed. :-)


I said:

>>In the long run, it will always be easier to maintain
>>a package if you use a package management system period full stop.
>>


And Haim Dimermanas replied:

 
> Not true.


Is it?  Let's see...


> Let's take 3 examples:
> 
> 1 - I want to use the latest xmms on my workstation and have the plugin for
> reading DivX :-) files.
> 2 - I want to use Apache with a custom module and some code tweaking.
> 3 - The Linux kernel.
> 
> The first example would be relevant in a workstation. If I install xmms from
> a package, chances are I won't get the latest version. When I need to
> compile my plugin, I will need the development files (includes and the
> like). I could find a package for that (by the way, rpmfind SUCKS for that)
> and go trying to get my plugin to compile. Most of the time, the dev
> packages are patched with some customization that the vendor made. It can
> get complex.
> 


Well, I think you chose a bad example there.  xmms comes with a .spec
file for building an rpm. :-)  Very often, however, even if a package
doesn't come with a spec file you can deduce from the previous spec
file what needs to be done for the spec file.  Saying it can get complex
is a bit misleading.  Yes, in a few cases it can get complex.  In the
vast majority of them, it's very simple.

In addition, at least with Mandrake, the packages in the Mandrake Cooker
(the experimental version) are updated with the latest version within
a day of two of release.


> The second example is obviously server side. If I need to server web page in
> the next 5 minutes, the rpm (or deb) for apache might do. If I need to get a
> real server up and running, I won't play with anything else than the source
> code. I will want to install come patches that will make my server respond
> better. Those patches might be unofficial (like the KeepAlive patch from the
> mod_backhand authors) but extremelly needed in my setup. There might be a
> security risk (there has been some lately with Apache). I do not want to
> depend on my vendor for fixing a security bug in a mission critical
> application. I am subscribed to apache-announce, I will get the patch
> myself, recompile, make install and thank you very much.


I run apache myself.  I have made several patches to it (i.e. setting up
the correct directory for suexec for my system) and use several non
standard modules.  I've compiled them all myself using rpm.  You can
still compile with source using rpm if you want to.  Without it,
however, I would have a hard time discovering just what all files were
installed, and if I upgraded, which ones got upgraded and which didn't.
And since rpm has dependencies (which, albeit are not perfect), I can
find out before an upgrade what all needs to be updated (rather than
just updating what I think needs updating and then finding out there
was something I missed).  It is just as easy (and I actually think
easier) to use rpm with custom patches as it is to do it by hand.


> My last example is the Linux kernel. The first thing I do once I finished
> the installation of a machine is compile a kernel optimized for that said
> machine. The difference in performance is very significant. I don't think I
> am alone in this way of doing things. Do you always use a kernel from rpm?
> If yes, you should try compiling your own one of these days and you will
> notice a huge gain.


Who says this can't be done with a package management system?  Besides,
these days, with the kernel being more and more modularized, this is
less of an issue.  If you can do it by hand, you can do it with rpm.
And what you gain by using rpm is way too much to just slough off by
saying "make install and thank you very much".


> I believe in good package management. That's why I use Debian. However, I am
> not a dependent on my package management system. If I need to do something
> out of the ordinary, I get the tarball and I document what I do.


What have I said that makes you think I'm dependent on my package
management system?  If I want a custom something, I can grab it,
make a few small changes to a specification file and get the best of
both worlds.  You really can have you cake and eat it too, here.

I said:


>>I generally find that those who claim otherwise don't really
>>understand or trust their package management system...
>>
 

And Haim Dimermanas replied:


> Interresting point. You're correct in a way. I do not fully understand dpkg.
> I wish I knew more about it but I haven't had the time to read the whole dev
> docs on debian.org (it's huge). As I said, a custom deb repository is on my
> TODO list.


Well, as I have said, I don't know the debian package management
system at all.  I'm sure however, that just about everything I say
about rpm can be transferred over to dpkg.

 
> A package management system is no substitute for a good documentation.


You are correct, but a package management system can be an integral
part of that documentation and free the admin to do much more
useful things.

Tanner
-- 
Tanner Lovelace | lovelace at wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
  Those who are willing to sacrifice essential liberties for a little
  order, will lose both and deserve neither.  --  Benjamin Franklin

  History teaches that grave threats to liberty often come in times
  of urgency, when constitutional rights seem too extravagant to
  endure.  --  Justice Thurgood Marshall, 1989




More information about the TriLUG mailing list