> I don't understand this statement. I have killed portupgrade on numerous > occasions, both locally and remotely, and have never had a problem > restarting later. If you mean portupgrade doesn't restart where it left > off, then yes, that's true, but only in the sense that it goes through all > the ports checking for upgrades before returning to the build you left off > at.
Actually I was wrong because portupgrade doesn't do what I want at all to begin with, so because nothing was ever started "correctly", there is nothing to resume "correctly". The intended situation was: Mini-port tree contains: A B C D depends on C Now, C is updated in the tree. You issue: portupgrade -r C If all goes well, C is rebuilt followed by D. But if interrupted after C, D won't get upgraded on a subsequent run because portupgrade does not know C was upgraded. Of course, this is based on portupgrading doing that to begin with and AFAIK this is not the case. I am not sure if any such logic is possible at all in fact. portupgrade -rf C works of course, ***IF*** you know that C was upgraded. What I lack is a "portupgrade -a --force-if-dep-was-upgraded", and even if that existed, the re-start problem would remain unless the fundamental approach was changed. (I have been meaning to fix this with my own package manager, but the project has been stalled for a while.) > I *really* don't understand this. I can count on one hand the number of > times that I've run into dependency problems with portupgrade, and all of > those were addressed in /usr/port/UPDATING or by simply deinstalling and > reinstalling the port in question. I would love to hear what I am doing wrong. I have just never ever had good experience with it. Everywhere you read on mailinglists or wherever, you have people recommending various versions (portupgrade -a, portupgrade -arR, etc) but none of it ever works over time for me. Firstly,there are these stale dependencies that are never explained anywhere as far as I can tell. I am also suspicious of the methology used that causes any kind of database / dependency inconsistencies as a matter of expected procedure. The job of the tool is to get my installed packages in synch with the ports tree; there is no possibilities for "stale dependencies" here as far as I can tell, except in some very specific cases. But everywhere I look in online resources these stale dependencies seem to be treated like some kind of unexplained-yet-necessary fact of life that nobody understands but that everyone seem to have a vague sense about. (I do realize upgrading is difficult in several fundamental ways; I wrote pkgmanager to do in-place upgrading for pkgsrc in a manner similar to portmanager - so I do have some experience with this. The re-write of pkgmanager to also support ports is what I refer to above. But with all the kinks of pkgmanager, the fundamental approach worked very well in practice, modulo some issues that have to do with lack of implementing particular cases, or fundamental problems in the underlying package management system.) Secondly there are various magic failures that start happening as a result of some dependency X being upgraded (or NOT upgraded) such that the other package Y depending on X breaks. This typically gets resolved by concluding that "ok, it's all borked, I'll portupgrade -rf Y" (or portupgrade -Rf X, depending)). Generally, these failures can be characterized as being such that they do not occurr if you 'make install' on a clean system with a consistent ports tree, but only occurr as a side-effect of problems with the upgrading procedure directly, or indirectly because packages are tested on fresh trees and do not stress dependency edge cases. Note that all this is specific to wanting to synch ALL packages. I never go around "sniping" at particular packages since i consider that to be a fundamentally broken approach in most situations. I just want to have everything upgraded to their latest versions (with security fixes), not have to micro-manage individual packages. Also, I do pay attention to /usr/ports/UPGRADING, but issues accounted for there definitely to not cover all the problems. Actually. Is there anyone heavly involved with ports that might be interested in discussing some of the issues having to do with upgrading? I have my own private little vision of what I want to see from ports/pkgsrc itself to enable package managers to support seamless upgrading. If there could be some cooperation going in terms fo enabling upgrading tools to work better, I might be more motivated to finally resume work on that pkgmanager rewrite. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
signature.asc
Description: This is a digitally signed message part.
