Date: Tue, 25 Dec 2007 01:58:24 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-questions@freebsd.org Cc: Paul Schmehl <pauls@utdallas.edu> Subject: Re: Updating ports Message-ID: <200712250158.34124.peter.schuller@infidyne.com> In-Reply-To: <1922FF4D9B0F57F56811A4DC@paul-schmehls-powerbook59.local> References: <221c791e0712220839v67a02e78q7cd5519f9b05a210@mail.gmail.com> <200712230119.30705.peter.schuller@infidyne.com> <1922FF4D9B0F57F56811A4DC@paul-schmehls-powerbook59.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart25502341.JQUCCJaeLB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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= =20 begin with, so because nothing was ever started "correctly", there is nothi= ng=20 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= =20 won't get upgraded on a subsequent run because portupgrade does not know C= =20 was upgraded. Of course, this is based on portupgrading doing that to begin with and AFAI= K=20 this is not the case. I am not sure if any such logic is possible at all in= =20 fact. portupgrade -rf C works of course, ***IF*** you know that C was upgraded. W= hat=20 I lack is a "portupgrade -a --force-if-dep-was-upgraded", and even if that= =20 existed, the re-start problem would remain unless the fundamental approach= =20 was changed. (I have been meaning to fix this with my own package manager, but the proje= ct=20 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= =20 experience with it. Everywhere you read on mailinglists or wherever, you have people recommendi= ng=20 various versions (portupgrade -a, portupgrade -arR, etc) but none of it eve= r=20 works over time for me. =46irstly,there are these stale dependencies that are never explained anywh= ere=20 as far as I can tell. I am also suspicious of the methology used that cause= s=20 any kind of database / dependency inconsistencies as a matter of expected=20 procedure. The job of the tool is to get my installed packages in synch wit= h=20 the ports tree; there is no possibilities for "stale dependencies" here as= =20 far as I can tell, except in some very specific cases. But everywhere I loo= k=20 in online resources these stale dependencies seem to be treated like some=20 kind of unexplained-yet-necessary fact of life that nobody understands but= =20 that everyone seem to have a vague sense about. (I do realize upgrading is difficult in several fundamental ways; I wrote=20 pkgmanager to do in-place upgrading for pkgsrc in a manner similar to=20 portmanager - so I do have some experience with this. The re-write of=20 pkgmanager to also support ports is what I refer to above. But with all the= =20 kinks of pkgmanager, the fundamental approach worked very well in practice,= =20 modulo some issues that have to do with lack of implementing particular=20 cases, or fundamental problems in the underlying package management system.) Secondly there are various magic failures that start happening as a result = of=20 some dependency X being upgraded (or NOT upgraded) such that the other=20 package Y depending on X breaks. This typically gets resolved by concluding= =20 that "ok, it's all borked, I'll portupgrade -rf Y" (or portupgrade -Rf X,=20 depending)). Generally, these failures can be characterized as being such=20 that they do not occurr if you 'make install' on a clean system with a=20 consistent ports tree, but only occurr as a side-effect of problems with th= e=20 upgrading procedure directly, or indirectly because packages are tested on= =20 fresh trees and do not stress dependency edge cases. Note that all this is specific to wanting to synch ALL packages. I never go= =20 around "sniping" at particular packages since i consider that to be a=20 fundamentally broken approach in most situations. I just want to have=20 everything upgraded to their latest versions (with security fixes), not hav= e=20 to micro-manage individual packages. Also, I do pay attention to /usr/ports/UPGRADING, but issues accounted for= =20 there definitely to not cover all the problems. Actually. Is there anyone heavly involved with ports that might be interest= ed=20 in discussing some of the issues having to do with upgrading? I have my own= =20 private little vision of what I want to see from ports/pkgsrc itself to=20 enable package managers to support seamless upgrading. If there could be so= me=20 cooperation going in terms fo enabling upgrading tools to work better, I=20 might be more motivated to finally resume work on that pkgmanager rewrite. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart25502341.JQUCCJaeLB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHcFW5DNor2+l1i30RAnEZAKDI02TtbeknQx8hqJ8j0pYQtgv2/wCgw1Bj ZLPPSTEgrWuAci7RZY7z3Ww= =gK/M -----END PGP SIGNATURE----- --nextPart25502341.JQUCCJaeLB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712250158.34124.peter.schuller>