[PLUG] Looking for an rpm feature

Wil Cooley wcooley at nakedape.cc
Mon Mar 25 07:14:37 UTC 2002


Also Sprach Michael Robinson <robinsom at opusnet.com> on Sun, Mar 24, 2002 at 10:43:08PM PST
> Michael Robinson
> 
> I've noticed during the Red Hat install that it is not only able to
> determine files needed to satisfy an rpm but the rpm that has to be
> installed as well.  Is there a way to get this functionality after the
> install?  I've heard a number of people have problems satisfying
> dependencies with rpm which is supposed to reduce the dependency problem.
> It would sure be nice if the rpm package manager forced package builders to
> sign their packages.  In reality I think google offers more help when it
> comes to upgrading software than rpm.

With Red Hat's own packages, you can install 'rpmdb-redhat' and use
the '--redhatrequires' and '--redhatprovides' query flags to find out
which packages will provide which files or require which packages.
Otherwise, no; because there are half a dozen distributions using RPM
and each making it's own packages, which aren't always compatible.

> It's annoying when a rpm -verify on a freshly installed Redhat system
> generates a whole bunch of md5, time, and other failures leaving no way
> to know for sure later if something really has happened to important
> files aside from installing and using tripwire.

Tripwire is really the right way to do this; 'rpm -V' only records
file attributes at installation.  My 'rpm -V' is usually pretty
comprehensible; the md5, size, time only change on files in /etc.
But Tripwire is really the right tool for this job (yeah, I know
it can be a PITA to get running).

> RPM is a fine idea, but if it isn't implemented well ( developers taking a
> hammer to the database before packages such as bastille can be installed )
> there's far less of an advantage over just using tarballs.

Not sure what you mean here.
 
> Is there a way to find out if an rpm will replace files as upgrading will,
> albeit not always, break programs?  If rpm wants to replace files what
> tricks are available to get both the old and new files installed, e.g. the
> gcc libraries?

You can find out which files the rpm contains with 'rpm -qlp
example.rpm'.  Some packages are designed so you can install multiple
versions, like the kernel packages.  None of the kernel files are
the same, so it's not a problem.  It's a problem when two packages
want to install /usr/bin/foo; there's no way to do it cleanly.
For GCC parts, you can often just install multiple together.
But do to that you have to install (-i) not upgrade (-U).

> What does rpm --rebuilddb do to rebuild the package database?

Not sure.
 
> My thought is that an unsigned package should be treated like a corrupt
> package.  Why are so many packages unsigned?

Because people don't use crypto?  All of Red Hat's packages
are signed; if you're not getting an gpg on 'rpm -K' then
you've not got the key in your keyring.

> Can tarballs be turned into rpms and those rpms then be used to replace
> some of the packages in a distribution tree like Redhat or Mandrake?
> For reasons unclear to me programs that should be chroot such as ftp,
> bind, apache, etc.  often come otherwise in standard distribution
> packages.  Why don't distributors want to compile programs chroot?

It's a lot of work to make sure the chroot'd stuff works properly.
It'll break lots of people's assumptions about where things will be
and how they'll work, so it'll break admin tools, homebrew scripts,
operator instructions, etc.  But I agree; I wish more stuff came
chroot by default.

Wil
-- 
Wil Cooley                                 wcooley at nakedape.cc
Naked Ape Consulting                        http://nakedape.cc
irc.linux.com                             #orlug,#pdxlug,#lnxs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.pdxlinux.org/pipermail/plug/attachments/20020324/8541ec16/attachment-0001.asc>


More information about the PLUG mailing list