Re: Why are depends rebuilt on "bmake update" ?

[Aleksej Saushev <asau%inbox.ru@localhost>]

Greg Troxel <gdt%ir.bbn.com@localhost> writes:

> 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.

I find it easier to maintain the list of packages that I need, this
serves as pkgchk.conf as well. It provides "deployment plan" (pkg_chk -kas),
"update plan" (pkg_chk -ukas), and recovery plan in case something goes wrong.

I agree that maintainance window may be longer with this approach,
but I find it more managable.

> 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.

I think I should try to explore this approach better.


-- 
HE CE3OH...