Brian T. Schellenberger wrote:
> Mike Corbeil wrote:
>
> > [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.
>
> Uninstall only un-installs what the package *thinks* it installed; once
> you start messing around with the rpm options you can confuse this
> process.
Uninstall can only remove something which has been installed, previously,
regardless of whether the uninstall works correctly or not. You cannot delete
something which doesn't exist.
However, it is important to know that rpm can be caused to screw up, albeit this
should not happen and is indicative of bugginess.
> I have found that the best approach is to install/re-install individual
> packages from hither & yon as infrequently as possible; unless you have
> some specific reason to do so, stick to the packages that all came
> together on your distribution.
There's no reason to install or reinstall unless the package is of use. Over
the past couple of months, I've reinstalled many packages, because I'm upgrading
the distribution and many packages need to be upgraded. This is one example
where installing updates is important.
Of course, I could purchase a new boxed edition, delete the old configuration
and install the new one, but I'm doing the upgrade manually. In the process,
I'm learning considerably, and learning is important, if not essential;
essential for me anyway, because working with computers isn't a mere hobby for
me. This also happens to help find bugs and therefore help to improve tools or
applications.
For entire newbies, I'ld suggest installing from a packaged cdrom.
> I, at least, find it easier to just backup my system and re-install
> periodically just to "keep up with what's new" and only install
> piecemeal when I have a specific bug or problem.
That's the recommended way, but if doing upgrades entirely with downloads, and
upgrading is definitely appropriate, as it is in my case, then this is an
exception. I believe this is covered in the Software Building HOWTO, or is in
some other LDP documentation.
In the process, I'm learning ample, and have already discovered a couple of
bugs, perhaps one only being a near bug, which will be useful in improving the
reliability, fool proofness, of the tool these bugs occurred with.
A very important and useful approach to developing sw is to apply the "what if"
strategy or approach. "What if the user does ..., will our sw be able to handle
the situation, and is it worth considering, because developing sw does require
time?". Often, sw is developed with inadequate emphasis on the "what if"
approach, but that's the only way to develop reliable sw the first time,
instead of relying on end users or customers having problems with one's sw.
Zacharie Richard sang "travailler est trop dur et voler n'est pas beau", but
there was no real conclusion ("working is too difficult or hard and stealing
isn't nice").
mike
> >
> > > 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.
>
> rpmdrake is a GUI on top of RPM, not a replacement rpm.
> In general packages don't install next to other packages, they replace
> them.
> I know of no reason why it wouldn't work with RH.
>
> >
> > 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.
>
> I always install non-RPM code to /usr/local. Much safer.
>
> >
> > mike
>
> --
> "Brian, the man from babble-on" [EMAIL PROTECTED]
> Brian T. Schellenberger http://www.babbleon.org
> Support http://www.eff.org. Support decss
> defendents.
> Support http://www.programming-freedom.org. Boycott amazon.com.
