Quoting Arnaud Abelard <arnaud.abelard(a)sciences.univ-nantes.fr>:
> 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.
No. Like Thomas said, using --nodeps doesn't make the software magically work.
That's a packaging issue, nothing to do with the tools - if rpm/apt/yum/etc
start second-guessing "hmm we have a dependency on foo-2.2 and we only got foo-
2.1 available here, oh i guess thats close enough" we're in deep trouble.
>
>
> 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
Purposefully installing software with incorrect dependencies and hoping it'll
work anyway is not a solution. However there *are* times when overriding the
normal check on rpmdb consistency would be extremely handy: usually when a dist-
upgrade has blown up in middle leaving the rpmdb in a state which is impossible
to fix by any single operation ("-f install" or manually upgrading things).
Then it becomes really painfull trying to salvage the system by manually
downloading and installing rpm's when apt *could* do it as well, weren't it for
the consistency checks. I once tried adding an option to disable the checks but
it's far from trivial, the "package database must be consistent at all
times"
is bolted deep into the design.
I can't figure what's YUM's behavior in that case.. will it refuse to
install new rpms too?
Yum only cares about the transaction at hand being consistent, it doesn't check
rpmdb consistence as such. Ditto for up2date and anaconda, don't know about rc.
--
- Panu -