FreeBSD Security Survey

[Chris H.]

Quoting Paul Allen <nospam at ugcs.caltech.edu>:

>> From Scott Long <scottl at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>



-- 
Shameless self-promotion follows...
... or does it?


-----------------------------------------------------------------
FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006
/////////////////////////////////////////////////////////////////

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: PGP Digital Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060523/e1aa4e98/attachment-0001.pgp