http://www.owlriver.com/tips/rpm-nodeps/
From herrold@owlriver.com Wed Jan 1 16:47:30 2003
Date: Wed, 1 Jan 2003 14:14:02 -0500 (EST)
From: R P Herrold <herrold@owlriver.com>
Reply-To: mdlug@mdlug.org
To: Metro Detroit LUG <mdlug@mdlug.org>
Subject: [MDLUG] Just say 'No' to '--nodeps' was: Re: [MDLUG] Updating KDE...
On 31 Dec 2002, jorge o. castro wrote:
> oops, misspoke, that should read "I've always preached that unless you
> REALLY REALLY know what you are doing (been using linux for 5 years and
> I don't consider myself in that category) then DON'T just --force
> things."
'whew' -- I was wondering when I read your first post.
Fortunately, 'no harm, no foul' applies -- A bare '--force'
without the '--nodeps' would not have broken the install. RPM
would still have refused to do the overwrite which the
'--force' authorized, because there would still be conflicting
dependencies.
As a capsule summary, here are a set of rules on RPM usage of
'--force' or '--nodeps':
1. Unless you can articulate WHY you need to use '--force' or
'--nodeps', you don't know and are guessing.
Voodoo sysadminning -- waving a rubber chicken at a problem --
is only entertaining to watch and NOT to experience, and is
only effective to repair a problem if the sysadmin is extremely
lucky.
2. '--force' is fairly non-intrusive as a lone rpm option --
it says: Reextract and overwrite existing binaries which are
other protected against overwrite by RPM and run the
pre- and post-install scripts. This might be done if you
inadvertently corrupt a binary in a 'piping' accident.
example -- say it got broken thus:
cat /etc/resolv.conf > /bin/mail -s 'debug resolv.conf' \
someone@example.com
When run as root that command will happily destroy /bin/mail.
We can still see that /bin/mail is part of the mailx package:
# rpm -qf /bin/mail
mailx-8.1.1-26
and repair it:
# rpm -U --force mailx-8.1.1-26.i396.rpm
which will over-write the corrupted version with a pristine
one. Assuming that the dependencies for mailx were already in
place -- which will be true so long as no '--nodeps' were ever
used, you are back in business.
3. '--nodeps' is extremely dangerous, especially when used
with libraries. It removes the install tool protections which
prevent mixing differing API levels on a system. Some may still
work, others fail without diagnostics which permit lay persons to
fathom what happened. This is familiar in the Windows 9x
operating systems too, which lacked strong install tool
protection of 'DLLs', causing "dll-hell".
Sometimes, space on a system is tight, and one has to run a
series of RPM commands to squeeze into a too-small /var. /lib,
or /usr/share -- by stopping and restarting processes which
used (and held open library files, so as to prevent release of
their inodes), one can get that former library space back, and
keep a running system up.
4. When you think you need to use '--nodeps', consider
solving the build tree dependencies instead, and building
from source SRPMs. The GPL, and RPM makes this easy in the
Open Source world.
... I just checked over 10000 lines of root and sudo-ed root
command history on several hosts, and cannot find a _single_
time I have had to use '--nodeps' on any of those hosts. I am
quite active in packaging, test the Red Hat RawHide and Beta's
daily, and run all the latest KDE, Gnome, and lots more. In
building and testing over 1000 RPMs from sources on one host,
[herrold@ftp RPMS]$ pwd ; find -name '*rpm' | wc -l
/home/herrold/redhat/RPMS
1119
It was all done without '--nodeps'. The methodology used to
attain this was to build from sources on a build host,
relentlessly and to solve dependencies at build time -- SRPM
packaged content makes this straightforward, and even
automatable. And good .SPECfiles protect config files, and
transition them when needed with post-install scripting so
upgrading 'just works.' (unlike a 'ports' system
./configure ; make ; sudo make install'
or pkgtool methods).
Note that .DEBs can attain the same results when well done --
but the released pace of Debian 'stable' (which is the 'well
done' branch) is _so_ glacial that one sees much less of the
leading edge stuff cleanly and safely installing.
so: Just say 'No' to '--nodeps'
-- Russ Herrold
We make this available for non-commercial and individual use.
Please respect our copyright, and consider contacting us for
all your Open Source and *nix design, architect / systems analysis, and
administration needs.
