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.