Quoting Paul Allen <[EMAIL PROTECTED]>:
From Scott Long <[EMAIL PROTECTED]>, Sun, May 21, 2006 at 11:44:27PM -0600: I share this frustration with you. I was once told that the pain in upgrading is due largely to a somewhat invisible difference between installing a pre-compiled package, and building+installing a port. In theory, if you stick to one method or the other, things will stay mostly consistent. But if you mix them, and particularly if you update the ports tree in the process, the end result is a bit more undefined. One thing that I wish for is that the ports tree would branch for releases, and that those branches would get security updates. I know that this would involve an exponentially larger amount of effort from the ports team, and I don't fault them for not doing it. Still, it would be nice to have.Huh? Really. What you say makes a certain amount of sense when pkg_add is used, but I haven't seen much evidence for problems with mixing ports and packages via portupgrade -P.The trouble comes not with packages but in the conflicting information between/var/db/pkg/ and the ports themselves. The former does not merely contain a stale version of the port dependency and origin information; it containsmany snapshots of small slices of many different port dependency graphs (as theport tree evolves). Consistently using portupgade -rR, portinstall helps keep this under control but each pkg_add or make install in a port directory causes drift. Giventhat portupgrade is an optional tool and the handbook suggests the other form...well you see the trouble. But the situation is worse than this because of the manual interventions necessary to fixup the portsdb. These fixups easily create dependency graphs that never existed anywhere else before. Most often this happens because ofports being renamed, deleted, combined, etc--the trouble here is that the portstree reveals no history about these actions. It is left to a program like portupgrade to heuristically guess!?! what hastaken place. Now if you go through this process every week (every day?) usuallythe risk is small and it is obvious what to do, but this is not always so. Some speculation: I've always thought portupgrade did the Wrong Thing(tm) by consulting the dependency graph in /var/db. Better to merely learn which packages were installed and then exclusively use the port information... Maybe someone knows why that would be the wrong thing to do?
May I insert a "me too" here? This (everything you've written here) has been my *only* reason for choosing not to upgrade immediately. I find the ease of using the ports system *glorious*, *_until_* it comes time to upgrade (installed ports). This is especially true when you have imposed subtle changes (inserted default options for the build/ install, created/ crafted ini/ conf files). Using make.conf *seemed* like the ultimate solution. That is, until you've found that you were on the leading edge of a major revision of a port, and those options are no longer supported, or have been renamed. Still, make.conf is a wonderful tool. But even w/o custom options/conf's inposed, upgrades through portupgrade (from myexperience) is a trip to hell. That I never look forward to re-living/visiting.
In short; there *must* be a better (less painful) way to handle upgrading the _installed_ ports. I only wish I could figure one out. Please note; this is a solicitation. ;) I am only adding (augmenting) to what Paul has stated here. (I build/manage some 50 FreeBSD boxes. So you can imagine the grief.) --Chris H.
Paul
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- Shameless self-promotion follows... ... or does it? ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 /////////////////////////////////////////////////////////////////
pgpRtA6dfllA3.pgp
Description: PGP Digital Signature
