Date: Tue, 23 May 2006 04:02:58 -0700 From: "Chris H." <fbsd@1command.com> To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Security Survey Message-ID: <20060523040258.agfxm26ngo44ggss@webmail.1command.com> In-Reply-To: <20060522061722.GA28128@groat.ugcs.caltech.edu> References: <4471361B.5060208@freebsd.org> <20060521231657.O6063@abigail.angeltread.org> <44714FBB.4000603@samsco.org> <20060522061722.GA28128@groat.ugcs.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed. --=_hjk355868dc Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Quoting Paul Allen <nospam@ugcs.caltech.edu>: >> From Scott Long <scottl@samsco.org>, 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 contains > many snapshots of small slices of many different port dependency > graphs (as the > port 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. Given > that 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 of > ports being renamed, deleted, combined, etc--the trouble here is that > the ports > tree reveals no history about these actions. > > It is left to a program like portupgrade to heuristically guess!?! what has > taken place. Now if you go through this process every week (every > day?) usually > the 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 my experience) 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Shameless self-promotion follows... ... or does it? ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// --=_hjk355868dc Content-Type: application/pgp-signature Content-Description: PGP Digital Signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEcuviXxK1cRs0zxkRAq5+AJ97LLlNOxMFaDCmZMk0XcYFEzfQfwCePZ27 VAymxtZ5Abr71g47DWDdxVg= =dikp -----END PGP SIGNATURE----- --=_hjk355868dc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060523040258.agfxm26ngo44ggss>