RELENG_8 buildworld broken?

Roland Smith rsmith at
Wed Dec 9 22:43:51 UTC 2009

On Wed, Dec 09, 2009 at 01:09:12PM -0800, Jeremy Chadwick wrote:
> The problem is this:
> - User installs OS
> - User creates src.conf with numerous WITHOUT_xxx entries.  Examples:
> - User is forced to go through above said directories and cross
>   their fingers hoping they're deleting the "right stuff".

Doing this right is not all that difficult when using find(1) and some common
sense. Maybe I'm too harsh, but someone who can't figure this out shouldn't be
messing with the system.

> Cons to this methodology:
> - User now has binaries and/or libs on their system which may contain
>   security holes that could be exploited if exploits/issues are found
>   in the future.  This is serious, and anyone who says otherwise has
>   their head in the sand.

Agreed. There should at least be mention of this in the src.conf manual page,
and probably in the handbook as well. Suppose I submit something like the text
below to be added to src.conf(5) or maybe the Handbook;


Adding options to /etc/src.conf does not remove old binaries, libraries or
manpages! It just prevents the system from buiding newer ones.  The best way
to deal with this is to use find(1) to locate binaries and libraries that are
older than the most recent installworld. E.g., supposing the latest
installworld (with the new options in /etc/src.conf) was Decemer 3rd. Running
the following command will reveal all older files

	find /bin -type f -and -not -newermt 'Dec 3' -ls 

After checking that you've really only found old binaries, replace -ls with
-delete. Next, repeat this with /sbin, /usr/bin, /usr/sbin, /lib, /libexec,
/usr/lib, /usr/libexec, /usr/share/man/man* and /rescue.


This strikes me as a reasonebly easy way to fix the problem.

Of course one could be fancy about presenting the old files;

	find /bin -type f -and -not -newermt 'Dec 3' -ls | \
	awk '{print $11, "\t", $8, " ", $9;}'

If someone was so inclined, it shouldn't be too hard to write a program to
more-or-less automate this; run all these commands, and append the output to a
file. The user would then be given the opportunity to tell which (if any) of
the old files to keep, and the program would then delete the others. Kind of
like mergemaster.

> Basically, all this comes back to the same thing: the entire "base
> system" concept needs to be revisited (that's a nice way of saying
> "nuked from orbit", but that's my opinion). 

Hmm, I kind of like having a usable base system as opposed to just a
kernel. :-) It is one of the strong points of FreeBSD, IMHO. The fact that the
base system is developed as a unit keeps it working very well.

But I can see the virtue in your approach as well. I wouldn't mind turning the
current base system into ports, but it would be a good thing IMO to keep
developing these 'ports' that form the current base system as part of the
system instead of in the ports tree.

[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-stable mailing list