From owner-freebsd-ports@FreeBSD.ORG Sun Mar 4 12:42:52 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 005E816A40F for ; Sun, 4 Mar 2007 12:42:51 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id AD0C513C4BC for ; Sun, 4 Mar 2007 12:42:51 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1HNq37-000177-9J; Sun, 04 Mar 2007 15:42:49 +0300 Message-ID: <45EABEA4.8020102@FreeBSD.org> Date: Sun, 04 Mar 2007 15:42:12 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.9 (X11/20070124) MIME-Version: 1.0 To: Vizion References: <20070303223856.LFYG2045.dukecmmtao03.coxmail.com@dukecmmtao03> In-Reply-To: <20070303223856.LFYG2045.dukecmmtao03.coxmail.com@dukecmmtao03> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org Subject: Re: PORTSUPDATING -is it too terse for users to be useful? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2007 12:42:52 -0000 Vizion wrote: > Hi > > Sorry to say I find this extract in PORTSUPDATING a bit too terse. I wonder if there could be some elaboration on the advice given in PORTSUPDATING for those who do not understand the implications. IMHO it is not very helpful to have an absense of procedural detail in such a critical file. > See illustrative questions below-- A purpose of UPDATING file is to give users a short note about changes in a port that may affect them. You can get details how ports work by reading Hendbook and Porter's Handbook. For certain ported software you will direct to the software documentation. > > 20070301: > AFFECTS: users of ports-mgmt/portupgrade* > AUTHOR: sem@FreeBSD.org > > Because of a bug in previous version, it's recomended you fill ALT_PKGDEP > QUESTION: OK what is this.. what does it do? > section in pkgtools.conf file for portupgrade be aware of alternative > dependencies you use, > > QUESTION: OK what is an alternative dependency? What procedure do we follow to find out which ones we use? A port may depend on other port(s). When the port installs, the ports system checks if dependencies are installed. If they are not installed, they will be installed before. Let's look on www/mod_perl as an example. It depends on a few ports. apache is one of them. Decision if apache installed or not takes by checking PREFIX/sbin/apxs file (Porter's Handbook describes how dependencies are defined). If the file does not exist, www/apache13 port will be installed. But if you have already www/apache13-modssl port installed, PREFIX/sbin/apxs will be in a place and dependency will be satisfied. There is no difference for the ports system between www/apache13 and www/apache13-modssl as a dependency. portupgrade rely only on information from port dependencies list (you can see it e.g. with 'make run-depends-list' from a port directory). And it knows nothing about www/apache13-modssl can be used instead of www/apache13. So it should be described in pkgtools.conf file as an example bellow. > > and run pkgdb -L to restore dependencies that was > lost. > > Example of ALT_PKGDEP section: > ALT_PKGDEP = { > 'www/apache13' => 'www/apache13-modssl', > 'print/ghostscript-afpl' => 'print/ghostscript-gnu', > } > QUESTION: Example is fine.. but what is a suffix? How do we identify the ones we need/use? > Note also, portupgrade knows nothing how to handle ports with different > suffixes (E.g. -nox11). So you should define explicitly variables > (E.g. WITHOUT_X11=yes) for the ports in /etc/make.conf or pkgtools.conf > (MAKE_ARGS section) files. OK. For -nox11 suffix you should define something like this: MAKE_ARGS = { '*-nox11*' => 'WITHOUT_X11=yes', } It should be work, but I did not test it. If I'll get a report that it works, I'll able to add this example. -- Dixi. Sem.