Which is a good thing. If you insist on running with inconsistent
rpm
databases, then your system is hosed by definition. In the case above,
if the rpm you want to install insists on the lower library (I don't
think I ever see many that do Requires: ... < (version)), then either
it's a packaging bug (the software works fine with this newer version)
or it's an actual situation where the newer lib doesn't work well (in
which case using --nodeps won't make the software magically work).
That's true, but in some case the inconsistency is unavoidable.. a
compiled library, or a more recent library than the one required by a rpm
(require: libsomething1.2.1 for example)
apt-get could warn the user and prompt them: "this can cause harm to your
system, are you sure you want to continue [Y/N]" or maybe implements a
--force mode. Of course that could be dangerous in certain cases.. not all
the time.
The only good argument for ever having an inconsistent database is those
precious few instances where you have to change versions on some
packages and between those versions the package set is done differently,
so you need to be inconsistent to remove parts and upgrade parts at the
same time.
So, thank you apt-get for not working when being inconsistent.
Yes, sometimes it's important to refuse working with a inconsistent rpm
db, but could be usefull to...security is important.. but sometimes taking
risks is the only solution
I can't figure what's YUM's behavior in that case.. will it refuse to
install new rpms too?
Thomas
Arnaud