remove BUILD_DEPENDS automatically after install

b. f. bf1783 at
Mon Nov 16 14:09:28 UTC 2009

>> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote:
>>> Is there a reason why BUILD_DEPENDS aren't being removed after a port
>>> has been installed and if no other installed port depends on it?
>> How do you know that the user does not want that port installed?
>> And what if the user will install 20 other ports afterwards - all of which
>> is that same port as a BUILD_DEPENDS - should that port be
>> installed/deinstalled each and every time?
>It would be nice if this was configurable. Maybe it could be even
>integrated into portupgrade or portmaster. If such a port is installed
>directly it could get a package entry DIRECT_INSTALLED=yes in
>/var/db/pkg/.. or something (there is probably a better way to do

How are you going to account for those ports that, while installed as
dependencies, the user nevertheless wants to keep for their own sake?
Or those that are installed individually by a user, perhaps to fix a
problem, but are not really wanted after all builds are done?  I think
that this kind of bookkeeping should be done by users and
administrators, and should not be cluttering up the ports and package
infrastructure.  If you really want it there, you can make your own
local modifications.

>> (Personally I would be *very* annoyed if, for example, libtool or
>> automake/autoconf would be reinstalled every time I installed a port which
>> had one of them as a build-time dependency.  There are *lots* of ports which
>> have one of them in BUILD_DEPENDS, but few if any that has them as
>Even nicer if execptions would be configurable. There are loads of
>ports that install BUILD_DEPENDS that are never used again. cvsup for
>instance pulls in a gigantic tree of esoteric ports I can't even
>pronounce. Sure I could install the package, take cvsup-without-gui or
>even use portsnap but this is not the point here.

I'm not sure what you mean by "exceptions" -- but if you are not
willing to consider dependencies and configure ports, then you really
ought to be using packages, and that is relevant to this discussion.

There are some ports that can help you manage this kind of cleanup --
for example, you could  run "portmaster -s", and then run "portmaster
-l", and remove those ports listed as leaf or root ports that you no
longer want. Or you could add entries to AFTERINSTALL in pkgtools.conf
to remove build dependencies when using portupgrade.  But it is
difficult to completely automate a removal, in a generic way that
would satisfy all administrators and users, so some interaction or at
least an initial configuration will be required.

Here is a shell script that will emit a list of installed ports that
are needed to build other installed ports, but are not needed by any
other ports at runtime, according to a ports tree.  You could run it
and then either pipe it's output directly to:

| xargs -I % make -C ${PORTSDIR:-/usr/ports}% deinstall

, or first filter the output to remove any ports that you want to keep:


_scriptname=`basename $0`
_listbuildreqs=`mktemp -t ${_scriptname}` || \
	echo "cannot create ${_listbuildreqs}"
_listrunreqs=`mktemp -t ${_scriptname}` || \
	echo "cannot create ${_listrunreqs}"

for _pkgorigin in `pkg_info -qoa` ; do

	for _buildreq in `make -C ${_portsdir}/${_pkgorigin} \
		echo ${_buildreq##*${_portsdir}} >> ${_listbuildreqs}

	for _runreq in `make -C ${_portsdir}/${_pkgorigin} \
		echo ${_runreq##*${_portsdir}} >> ${_listrunreqs}

sort -u ${_listbuildreqs} > ${_listbuildreqs}_sorted
sort -u ${_listrunreqs} > ${_listrunreqs}_sorted
comm -23  ${_listbuildreqs}_sorted ${_listrunreqs}_sorted
rm ${_listbuildreqs} ${_listbuildreqs}_sorted \
${_listrunreqs} ${_listrunreqs}_sorted

More information about the freebsd-ports mailing list