From owner-freebsd-questions@FreeBSD.ORG Sat Feb 24 19:02:52 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 705A316A401 for ; Sat, 24 Feb 2007 19:02:52 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 98AD413C467 for ; Sat, 24 Feb 2007 19:02:51 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.8/8.13.8) with ESMTP id l1OJ2U2C052493; Sat, 24 Feb 2007 19:02:30 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <45E08BC0.4040203@infracaninophile.co.uk> Date: Sat, 24 Feb 2007 19:02:24 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 1.5.0.9 (X11/20070120) MIME-Version: 1.0 To: Gerard Seibert References: <20070224101153.6b66fdc1@localhost> In-Reply-To: <20070224101153.6b66fdc1@localhost> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigEC67A54D9CFA2800D99ABD05" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Sat, 24 Feb 2007 19:02:46 +0000 (GMT) X-Virus-Scanned: ClamAV 0.90/2642/Sat Feb 24 15:58:41 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean Cc: freebsd-questions@freebsd.org Subject: Re: Forcing correct version of Clamav to be installed X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 19:02:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC67A54D9CFA2800D99ABD05 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Gerard Seibert wrote: > I recently contacted the maintainer of 'claws-mail' -- Alexander > Leidinger -- 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. >=20 > 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.= >=20 > 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=3Dyes APACHE_PORT?=3Dwww/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=3Dbar 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=3D ${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=20 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 --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enigEC67A54D9CFA2800D99ABD05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4IvG8Mjk52CukIwRCDXhAKCBG5jEqCyFcLWjQsYriPMTO1uBogCbBL4K RVGaAjDbPwm/xTOufQqxG30= =5GoH -----END PGP SIGNATURE----- --------------enigEC67A54D9CFA2800D99ABD05--