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

Haim Dimermanas dudle at linuxroot.org
Tue Oct 16 11:41:52 EDT 2001


Tanner Lovelace wrote:
> How is it easier in the long run?  It's certainly easier to
> forget exactly what files were installed with a particular
> package.  It's certainly easier to forget what libraries it
> depends upon (so you don't upgrade them out from underneath
> something).  It's certainly easier to forget that something
> depends on a package that you've installed by hand...

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

> It is certainly easier to forget just how you tweaked a
> particular package to get it to work with your setup...

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

> It's is *most certainly not* easier to maintain a package
> if you install it as a tarball.  Package management
> systems were invented for a reason.  People's minds are
> fallible.  They forget things.  These things are much
> more easily remembered with a database (either rpm or dpkg).

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.

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

Not true.

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.

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.

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.

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.
 
> I generally find that those who claim otherwise don't really
> understand or trust their package management system...

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.

> This sort of reminds me of the arguments of why people
> should comment code.  If you want any sort of chance
> of remembering what a particular piece of code did
> after putting it away for a long period of time (which
> can sometimes mean just days..) you'd better comment it.

I totally agree.

> Also, if you want to remember all the attributes of
> a package, you should use a package management system.

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

	Haim.
-- 
http://dudle.linuxroot.org



More information about the TriLUG mailing list