[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Why are depends rebuilt on "bmake update" ?
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
>>>> 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
>>>> to recover. This makes me believe that pkg_rolling-replace is not safe
>> "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
>>> 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
> 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
I think I should try to explore this approach better.
Main Index |
Thread Index |