Brian T. Schellenberger wrote:

>

[snipped]

> This sounds pretty odd to me.  I mean, if you get the latest sources and
> rebuild everything, then it should be reliable in that you know you
> built for your system with the same libraries, but RPMs should work
> well, too, most of the time.

The previously referenced documentation did say that RPMs should work well,
most of the time, but because of problems, at least in the past, the
document emphasized using .tar.gz sources, particularly instead of using
binary RPMs, but also in any case.

However, rpm has probably evolved since that documentation was written.
I've been using rpm all along, so far, but do run into dependency problems,
some which are a real pain in the neck.

>  And RPMS can contain before and after
> scripts to fix things up in case there's additional work to do.

Many of them seem to contain pre and post scripts.

>

[snipped]

> Well, if you *only* do --nodeps that's probably true, but if you use
> --force you can get in trouble: the un-install could un-install stuff
> that was really installed already.

un-install usually means removing stuff that was already installed, as far
as I'm aware.However, guessing, --nodeps could also cause problems.
According to the aforementioned referenced documentation, --nodeps can
install an app and this might work, but it can also cause other apps to be
"broken", and I don't have any difficulty believe that this is definitely
possible, and does happen.


> You might try rpmdrake; it can resolve dependencies and install them all
> automatically.

Thanks for that point.  Definitely sounds better than the rpm I'm currently
using, 3.0.2.  I've already found a couple of "bugs" with this version, one
when erasing or removing 3.0.2 after it's been installed "next" to a prior
version, and the other being that I now, somehow, have three instances of
3.0.2 reported with rpm -qa.  Not sure how the latter happened, but
definitely seems wrong.

On the other hand, the first bug is easy to recover from once one knows
how, especially if there's another Linux configuration files and
directories can be copied from, and the second bug doesn't prevent rpm from
working; just that there are more instances reported by rpm -qa than
necessary.  Guessing, I believe that this may be more of a rpm database
tracking error, but harmless.

I'll take a look into rpmdrake, and believe it works for both Mandrake and
RH.

Screwed up my test/build system tonight doing configure, make and make
install, for glibc2 2.x.x .tar.gz archive.  Can't boot into that
configuration any longer and now need to figure out how to undo  or
repair.  That teaches me one lesson, to not install to /usr, but instead as
the INSTALL file says to try first, to /usr/local.

mike


Reply via email to