Re: [expert] Re: Dependency help
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. 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. 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. 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.
Re: [expert] Re: Dependency help
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.
[expert] Re: Dependency help
Mike Corbiel wrote: However, one piece of documentation I came across yesterday said that this kind of problem is easier to avoid by avoiding RPMS and instead using .tar.gz downloads, and then running configure, make and install. Actually, this is the same piece of documentation first referred to, above. It said that RPMs are supposedly, considerably unreliable in this way, whereas downloading .tar.gz archives is considerably more reliable. 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. And RPMS can contain before and after scripts to fix things up in case there's additional work to do. Of course, one could always try these guidelines, or installing RPMs using the --nodeps (skip dependency checking) option, but I wouldn't do this without first backing up the system. On the other hand, it may not be necessary to backup the system, because if the --nodeps allows package installation and then apps don't work, then the package(s) can probably be removed without any problems. I don't know installation of RPMs well enough to be able to say this for sure, though. 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. You might try rpmdrake; it can resolve dependencies and install them all automatically. -- "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.
Re: [expert] Re: Dependency help
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
