On Mon, 18 Jun 2007, Marc Espie wrote:
packages without problems, no longer stops if an installed package cannot
be updated because of either ambiguities or missing packages (at least '-F
alwaysupdate' appears to be permanently in effect.)
This is something Theo demanded. He wants for updates to proceed even
if some packages cannot be found. Take that specific beef with him.
This does solve the very specific fringe case of third-party firmwares
not stopping an update.
Well, if it's For The Greater Good, I don't have any beef with it. Yarp.
From where I stand, it merely affects my personal use case. I'd like to
point out, however, that the documentation is no longer in sync with
reality.
Since I made good use of the original behavior, and others might do it in
similar ways, an option to revert to the original behavior would be nice,
though. Maybe an '-F error' or somesuch, which promotes the
warnings-that-used-to-be-errors back to errors (ambiguities, missing
packages.) That way, by ensuring that a central package repository is
clean, I can ensure that once an upgrade runs, it will be complete in the
end.
queued as "A, C, B", as usual. However, during the actual upgrade,
upgrading A failed because of a plist-related error/warning (sorry, I
don't remember the actual wording) - it couldn't read the plist of C-2,
which hadn't been upgraded, yet. Then, C and B were upgraded and after
rerunning pkg_add -u, A was upgraded as well. AFAIK this is new behavior
Looks like you run into a temporary bug (the plist-related error/warning
that you don't remember), this makes all the rest of that specific
discussion irrelevant... without knowing what was the contents of
various +REQUIRING/+REQUIRED files before/after the update, I can't
comment on what happened.
I still have Mr Server in our appartment that runs -stable, which I can
upgrade and try to reproduce. It might take a while, however, but when I
am able to, I'll make copies of /var/db/pkg/ from pre- and post-upgrading.
Moritz