Forcing correct version of Clamav to be installed

[Matthew Seaman]

Gerard Seibert wrote:
> I recently contacted the maintainer of 'claws-mail' -- Alexander
> Leidinger <netchild at FreeBSD.org> -- regarding a problem with that port.
> It wants to install 'clamav' even though I have 'clamav-devel'
> installed. Since these ports conflict, the install fails.
> 
> After talking to Alexander, he informs me that it is a generic problem
> with the ports system and that it should be fixed there. I haven't got
> the knowledge of how to accomplish this however. Instead, I modified
> the claws-mail Makefile to have it install clamav-devel rather than
> clamav. The problem is that portsnap will over write that change if and
> when it updates the port requiring me to manually re-edit the Makefile.
> 
> My question is how would I proceed to force any port that wants to
> install clamav to rather install clamav-devel? I have this problem with
> other ports and having to manually edit each Makefile is an annoyance,
> especially if I forget to make the changes.

Unfortunately there isn't a generic solution to this problem.  A
number of ports have made provision for allowing the user to switch
between several different possible versions -- for instance you can
set

    WITH_APACHE2=yes
    APACHE_PORT?=www/apache22

and anything that depends on apache will cause apache-2.2.4 to be
installed.  Similar schemes exist for perl, php, python, mysql,
openldap, java and many others.  Frequently this is marked by the
presence of a bsd.foo.mk Makefile in /usr/ports/Mk and the appearance
of USE_FOO=bar type constructs in the port Makefiles that depend on
this functionality.

Outside these sort of schemes, there are number of individual ports
let you choose between different upstream alternative dependencies
by using OPTIONS or other make variables -- the distinction here being
that they don't imply a global preference, rather they just control
the actions of a single port.

The root of this problem comes from how a port registers a dependency.
This example comes from one of the ports I maintain,
databases/mysql-connector-java:

RUN_DEPENDS=      ${JAVALIBDIR}/log4j.jar:${PORTSDIR}/devel/log4j

This says that at build time the ports system will check for the
existence of the file /usr/local/share/java/classes/log4j.jar
(assuming default values for the various other make variables involved).
If that file is not found, the build / install will chdir to
/usr/ports/devel/log4j and do a make install there to resolve the
dependency.

Once that is done the ports system will return to the build+install
of mysql-connector-java.  The subsequently installed mysql-connector-java
package will record the log4j package as one of its dependencies:

% pkg_info -r mysql-connector-java-\*
Information for mysql-connector-java-5.0.4:

Depends on:
[...]
Dependency: log4j-1.2.14

There are two gotchas with this scheme.  (Luckily neither of them
generally applies to the mysql-connector-java port...)

i) The test file (ie.in my example ${JAVALIBDIR}/log4j.jar) was
already installed, but didn't come from the suggested dependency port
(eg. ${PORTSDIR}/devel/log4j).  Either the log4j software came from
some alternative port, or it was installed outside the ports system
entirely.

Practically this makes no difference to the day to day use of the
installed package.  So long as the dependency contains the right stuff
to provide the needed functionality, everything is happy.  This is
actually one of the real plus points of the ports system: you can
override it when you need to.  So for the 'clamav' vs 'clamav-devel'
problem, as long as you simply install 'clamav-devel' first (and given
that both ports essentially install the same pkg-plist) then any port
depending on clamav will be satisfied when it finds the equivalent
test file from clamav-devel.

The difficulty comes when you attempt to maintain such ports with the
inaccurately registered dependencies.  portupgrade(1) for example will
require you to run 'pkgdb -F' in this situation, and it is frequently
not obvious what the correct answers are to the questions pkgdb asks.
Get it wrong and you'll tend to end up overwriting the software you
intended to install with whatever the ports system thinks is the
default.

The portupgrade(1) port however does contain a program that could
address this: pkg_which(1). This program looks to me like the eventual
basis for providing a general solution to this problem.  pkg_which
simply tells you which port installed the test file:

% pkg_which /usr/local/share/java/classes/log4j.jar 
log4j-1.2.14

Having that data readily available, it shouldn't be amazingly difficult
to alter the ports / packages system to record the dependency against
what package was actually installed.

Trouble is, pkg_which(1) is written in ruby, like the rest of the
portupgrade suite, and so is not a suitable program for inclusion
into the base system.


ii) The other general problem is that it may not be clear to the user
that there are alternatives available at port build or install time,
or indeed what those alternatives are.  Also precompiled packages have
the default dependency hardwired into them, and unlike compiling from
ports, installing package tarballs won't cause a check for a file or
shlib that indicates the prerequisite functionality is available: it
will simply check the directory of installed packages for evidence that
a specific dependency package has been installed.

In most of the common cases where alternative dependencies are available
in the ports, there will be a mechanism available for choosing
amongst various different ones coded into the port Makefile.

Generally there is no way of finding out what those options are short of
reading through all of the Makefiles involved in the dependency tree or
test installing the port and seeing what options are presented during
that process -- and test installing doesn't necessarily show you all of
the options anyhow.  While people like me are perfectly happy grovelling
through a pile of Makefiles, I understand that it can be intimidating to
novices, and besides, it takes longer than should be necessary however
familiar you are with make(1) syntax.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20070224/0bc97cbe/signature.pgp