Hi there,
It may happen that some people experience file index conflicts when trying
to update the libc packages. In this case, use the following command to
circumvent the checks:
rpm --nodeps --force -Uhv package.rpm
The reason for this is based on older versions of rpm as well as different
ways to index the manpages.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
* Roman Drahtmueller wrote on Thu, Sep 07, 2000 at 10:45 +0200:
In this case, use the following command to circumvent the checks:
rpm --nodeps --force -Uhv package.rpm
BTW, couldn't this cause problems? At this way it's possible to install rpms even when needed depencies are not present, so it should be used with care IMHO. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hi Steffen,
* Roman Drahtmueller wrote on Thu, Sep 07, 2000 at 10:45 +0200:
In this case, use the following command to circumvent the checks:
rpm --nodeps --force -Uhv package.rpm
BTW, couldn't this cause problems? At this way it's possible to install rpms even when needed depencies are not present, so it should be used with care IMHO. oki, Steffen
This is correct. I've seen conflicting manpages in one installation, but
experiencing this may also depend on the sequence of the rpm upgrade.
Since it's about manpages only, there's not much to lose if --force and
--nodeps become necessary.
I should have pointed out that you should always take a close look at what
the output without the force options is if you intend to force it. Manpage
conflicts are annoying, but by far not fatal.
In some cases, f.ex. if you want to install some RedHat rpm, it might be
necessary to use the two force options because Redhat uses different
symbols to address dependencies and provides. If you are in this
situation, you must resolve the dependencies by hand, in other words,
find and install the right SuSE library and then hammer the rpm from
another vendor. In most cases, you'll find the required packages (libs,
...) in the SuSE distribution.
Roman.
--
- -
| Roman Drahtmüller
Hi Roman, hi *! * Roman Drahtmueller wrote on Sat, Sep 09, 2000 at 01:30 +0200:
* Roman Drahtmueller wrote on Thu, Sep 07, 2000 at 10:45 +0200:
rpm --nodeps --force -Uhv package.rpm
BTW, couldn't this cause problems? At this way it's possible to
I should have pointed out that you should always take a close look at what the output without the force options is if you intend to force it. Manpage conflicts are annoying, but by far not fatal.
Yep, you're right of course.
In some cases, f.ex. if you want to install some RedHat rpm, it might be necessary to use the two force options because Redhat uses different symbols to address dependencies and provides.
I don't like such thing in production. I don't like RPM which cannot be installed without such force options, since it may result in trouble. For privates this is mostly ok, but not at all in production IMHO. Usually it's just a minor change in the spec File. unixODBC is an example: I needed to change just a single line. rpm -ba name.spec should do the rest :)
If you are in this situation, you must resolve the dependencies by hand, in other words, find and install the right SuSE library and then hammer the rpm from another vendor. In most cases, you'll find the required packages (libs, ...) in the SuSE distribution.
Yep, at this point there aren't big differences between distributions I think. But the names are different, i.e. the difference between "qt2" and "qtlib2". Usually it's easy to adapt the spec file and recompile. This is what RPM makes great I think. BTW, useing this I go for sure that I don't get dynamic link problems with some binary which is not used often or so. I know that there is a problem when makeing update packages with the depencies, but I don't have the time to search for an libauth.so.1 in some other RPM, or checking if the depency/conflicts are harmless or not. I wish SuSE would give some more detailed upgrade informations, like: "If you use this kernel update on suse prior 6.4 keep in track that lilo won't install the initrd. This may cause trouble on SCSI boot systems. In that case you have to install blah.rpm and edit the file foo.conf by changing alice to bob an rerun lilo..." So I had some trouble: I have to upgrade since there are security issues. But this isn't safe, and it may be possible that I "destroy" a productive server or router. I have a test machine with every running SuSE dist to "test" the upgrade before doing this in production. But this should be done by SuSE I think (I think you test your upgrades, and if there are some "special" actions they are known, so it shouldn't be a problem to describe those in the announcement). In some time, it should be possible to install gpg signed RPMs via some ssh -c connects pseudo-automatically. At least this is a wish by many users and administrators. This would reduce the total cost of ownership a lot. But this requires that the RPM upgrade/freshups don't cause any problems or conflicts, and I'm sure SuSE will offer this possibility soon! But for know I cannot "trust" your testers well, since some of the upgrade required manual actions and/or causes trouble (i.e. freeswan is not working after upgrade). In production this leads to an immediate downgrade of course, which re-opens the security holes... But usually there's no choice. So I would like if SuSE could improve the test policies a little :) What does the list think about this issue? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hi, I found the following entry in /var/log/warn: popper[22888]: Possible probe of Account xyz from host hostname What does this entry mean? Thanks in advance. Benjamin
participants (3)
-
Benjamin Janson
-
Roman Drahtmueller
-
Steffen Dettmer