Gerard Seibert wrote:
> I recently contacted the maintainer of 'claws-mail' -- Alexander
> Leidinger <[EMAIL PROTECTED]> -- 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 in
