Aleksej Saushev <asau%inbox.ru@localhost> writes:
> Greg Troxel <gdt%ir.bbn.com@localhost> writes:
>
>> Aleksej Saushev <asau%inbox.ru@localhost> writes:
>>
>>> I tried to recover from inconsistent "make replace" with pkg_rolling-replace
>>> several times and always ended in a state with even more inconsistencies.
>>> This led to rebuilding of all packages at least two times, and at least one
>>> time I could get out with pkg_chk. In other cases I performed manual updates
>>> to recover. This makes me believe that pkg_rolling-replace is not safe
>>> mechanism.
>
> "BUGS" section doesn't sound encouraging either.
Perhaps that should be reworded. The bit about significant numbers of
packages is there because I have found that typically, when doing make
replace of 300 packages, some won't build, and this is usually due to
underlying issues in pkgsrc (on head, bettter on stable branches).
As to the second point, package name changes are relatively rare. In
these cases make update isn't automatic either, nor is pkg_chk -g and
bulk build.
>> That sounds unusual. (If dependencies are not expressed correctly, it
>> can't work, but that doesn't sound like what happened to you.)
>>
>> Another problem I should have pointed out is that
>>
>> building packages from one pkgsrc version
>>
>> updating to newer pkgsrc (but not rebuilding anything)
>>
>> make replace on some random package
>>
>> pkg_rolling-replace -v
>>
>> will not work, because many packages will demand specific new versions
>> of dependencies.
>
> Alright, I see. It should build new dependency and stop at conflict.
And when this happens to me, I either do -uv, or I go to the place it
stopped and do 'make replace clean' and continue.
>> This is not actually a pkg_rr bug, but an underlying
>> reality of make replace. To avoid this, I do
>>
>> pkg_rolling-replace -uv
>>
>> which also replaces mismatched packages. Perhaps this is what you ran
>> into.
>>
>> If you have more data abou the problem you had (logs, etc.) I'd be
>> interested in seeing it.
>
> I don't have more data, it's been long since I used it last time.
> Problems that require hard work to recover don't encourage experimentation.
Sure. I have found that pretty much any way to update packages has
issues. The only simple path is to use a binary bulk build that someone
else did and worked through all the issues, but then there's no
customization, and it only works on systems where that's available.
(Your point about what happens when a package is replaced by a pair of
packages with a conflict from the old one to one of the new ones is
entirely valid; addressed separately by apb@.)
> Sorry, but the above convinces me that pkg_rr is still way too dangerous
> to recommend to those who may not understand the mechanics.
True. It's a useful tool for people who understand.
> First, it is too easy to omit "u" flag, thus a user may stick with
> inconsistent tree with no clear recovery plan.
But this user was already in a bad state, because updating /usr/pkgsrc
to a newer version and not changing binary packages to match, and then
trying to build things will not in general work.
> Second, its operation isn't trivial _enough_ so that a user could have
> enough clue on what's going on. You cannot expect that everyone knows
> what topological sort is and understands consequences. Documentation
> doesn't stress that either. Perhaps, man page should elaborate more
> how it actually works, so that a qualified person could have better
> grasp of underlying mechanics and could work out recovery plan.
Better explanations are certainly welcome.
> pkg_chk is more obvious and straightforward to work with, since it walks
> the dependency tree from given set of roots, and operator can just
> remove what gets in a way and continue. In case of pkg_rr recovery
> requires selectively removing a package that has active dependents,
> and you have to do it carefully so that you don't kill the whole tree
> of packages recursively. I admit that I might be biased towards pkg_chk,
> but that's what my experience is.
I think it's a question of which disadvantages you prefer.
With pkg_rr, most of the time, almost all packages continue to work
almost all of the time, but one runs into these tricky problems of
self-conflicts and renames.
With pkg_chk:
-u Automatically update any installed but out of date packages.
If a binary package exists in PACKAGES it will be used in pref-
erence to building from source, unless the -b or -s options are
given.
Note: If the update fails (particularly when building from
source), the system will be left with missing packages. Once
the error has been fixed, a second run will resume the update.
the issue is that make update (presumably that's what it does; that man
page isn't clear either :-) will fail part way through, leaving a
situation that is also very hard to recover from.
My view is that the only really safe approach is to pkg_chk -g, build
all packages in a chroot, and then only when that's done do a
remove/install. But I have found that using pkg_rr is less pain for me
overall.
Attachment:
pgppJuovQBEob.pgp
Description: PGP signature