[lug] Debian is better?

[Nate Duehr]

I just want to know why you can --force an install but not an 
UN-install... with RPM.  That's super-duper-lame.

That one really chaps me sometimes when I *know* I want a package 
gone...  I'm the damn sysadmin, not RPM!  (Of course there are ways 
around this, but then your RPM database isn't really correct without 
more work.)

An example, say I've compiled my own version of Apache someplace on the 
filesystem and would like to remove the httpd package... without 
removing all the OTHER things that depend on having Apache around.  With 
other package tools they give me the option to shoot myself in the foot 
if I want to... RPM refuses to allow it.

I don't know how I feel about that.

And no, I can't make an RPM for every custom version of Apache... let's 
say I'm running ten of them.  All compiled differently.  But they can 
and should be able to SHARE stuff like php binaries... and I should be 
able to force the removal of RedHat's package.

Anyone know the history behind why they don't allow for this in RPM?  Or 
some way to do it "cleanly"?

Nate


Sean Reifschneider wrote:
> On Wed, Dec 18, 2002 at 04:24:30PM -0700, David Morris wrote:
> 
>>problems in 7.something as well.  The problem is not that
>>there is no dependancy checking, but rather that there is no
>>dependancy *requirement*.  The RPM format itself does not
> 
> 
> I don't really follow you here...  If you run "rpm -i somepackage" and
> don't have the proper dependencies installed, rpm will fail unless you
> install those dependencies, or run it with "--nodeps".  If you install
> an RPM with --nodeps, you will cause problems just like if you get a
> .deb that requires things you don't have and install it with
> "--force-depends" on Debian.
> 
> What most people describe as "dependency hell" or dependency problems I
> think is just that they're not using a very advanced tool.  "rpm" on Red
> Hat is like "dpkg" on Debian...  It's a low-level package manipulation
> tool.  Neither one tracks down dependencies on it's own, etc...
> 
> There are more advanced tools available for both Red Hat and Debian.  On
> Debian, the preferred one seems to be "apt".  With Red Hat you also have
> "apt" available, as well as things like "krudfind" and other tools that
> will resolve dependencies, etc...  krudfind has the benefit that you
> dont' have to know the package name -- you can just ask it to install
> "/usr/sbin/smbd", and it will pick that up and any required deps...
> 
> The real strength I see in Debian is the large centralized software
> repository.  There are a lot of packages out there for Red Hat that are
> either not updated or sometimes just plain broken...  Lots of people
> seem to run into problems because they are running 8.0, for example and
> install packages for 7.0.
> 
> My word of advice there is: Don't be afraid of SRPMs (source RPMs).  If
> you pick one up and do "rpmbuild --rebuild whatever.src.rpm", it will
> build binary RPMs that exactly match the set of packages you have
> installed -- wether you're running what Red Hat ships, or have upgraded
> this or that...
> 
> 
>>cannot install the package improperly even using dpkg,
> 
> 
> Not true -- see the dpkg man page under "--force".
> 
> Sean