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