From owner-freebsd-ports@FreeBSD.ORG Thu Aug 27 04:29:12 2009 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 859C7106568C; Thu, 27 Aug 2009 04:29:12 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 57AD58FC2E; Thu, 27 Aug 2009 04:29:12 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n7R4TA7a030306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Aug 2009 21:29:11 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5FA821CC09; Wed, 26 Aug 2009 21:29:10 -0700 (PDT) To: Peter Pentchev In-reply-to: Your message of "Thu, 27 Aug 2009 02:10:06 +0300." <20090826231006.GA1079@straylight.m.ringlet.net> Date: Wed, 26 Aug 2009 21:29:10 -0700 From: "Kevin Oberman" Message-Id: <20090827042910.5FA821CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-27_02:2009-08-26, 2009-08-27, 2009-08-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0907200000 definitions=main-0908260246 Cc: ports@freebsd.org, ahze@freebsd.org Subject: Re: serpentine port forces dependency on muine 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: Thu, 27 Aug 2009 04:29:12 -0000 > Date: Thu, 27 Aug 2009 02:10:06 +0300 > From: Peter Pentchev > > On Wed, Aug 26, 2009 at 11:47:48AM -0700, Kevin Oberman wrote: > > > Date: Wed, 26 Aug 2009 07:05:12 +0100 > > > From: Matthew Seaman > > > > > > Kevin Oberman wrote: > > > > > > > If muine found in /usr/local/bin/, it will be built with the plug-in, > > > > regardless of which way the MUINE configure option is set because: > > > > .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386" > > > > > > This is incorrect behaviour in any case: ports should not arbitrarily change configuration depending on what is or is not already installed, and user > > > choices from OPTIONS dialogues should be paramount. The test should be: > > > > > > .if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386" > > > > > > The more I look at this port, the stranger it is. > > Uhm, no it isn't, not really :) > > > It has OPTIONS=, but does not include bsd.port.options.mk. > > It includes bsd.port.pre.mk before testing the option. The part that > takes care of displaying the dialog window to the user is in > bsd.port.pre.mk. This part of the port's Makefile is correct. Whole this may work, it is not recommended by the Porter's Handbook. (See 5.11.2.2). Still, I suspect it does work as used here. > > > It then uses tests on a variable named MUINE (same as the option), > > not WITH_MUINE or WITHOUT_MUINE. > > No it doesn't. The port's Makefile uses tests on WITH_MUINE (line 32). > It then adds a variable named MUINE to the PLIST_SUB - the variable > that contains the substitutions to be made in the pkg-plist file. > And indeed, the pkg-plist file contains a couple of lines with > %%MUINE%% in them - that part works, too, because the port adds > MUINE to PLIST_SUB. This part of the port's Makefile is also correct. Yes, I was wrong about this. > > This effectively makes the "option" not an option, at all. Serpentine > > is ALWAYS built with the muine plug-in and, since the muine port is > > broken (probably forever), this effectively breaks serpentine. > > No it isn't. Serpentine is always built with muine *only* if the muine > port is installed on the system at the time serpentine is build, as > I explained in the previous message. > > Witness - on my system, where I *don't* have muine installed: Yes, this right, too. > There is some sense. As I explained in my previous mail, this will > work just fine if the muine port is not installed on the system at > the time serpentine is built. This is true for the package building > cluster, and it is true for some of us who build our ports this way. > > Now... I do agree that having a port change its behavior depending > on what is installed on the system is not really a good idea. It used > to be considered a good idea - I remember a time when many, many ports > did this instead of making the user define lots of variables when > the options framework did not exist yet :) The idea was to make it *easy* > for the user - if she has installed muine, then she most probably *wants* > other apps to support muine, so the serpentine port just goes ahead and > does the right thing without asking. Probably the WITH_MUINE knob was > present even then, before the options framework - and many people > considered this actually comfortable - "Yes, I know I can define this > variable to make serpentine build with muine support, but I don't even > have to do this - I just build muine beforehand and it's all right". > > Even then, I was one of the people who didn't like this, and I removed > such autodetection in all the ports I took over, years ago. Still, > other maintainers felt that this was useful and comfortable for the users. > > This behavior should have been removed when the OPTIONS variable was > added to the port - now there *is* an easy way for the user to specify > whether she wants muine or not. This part I agree with, and I think > that it should be removed now. > > I'm just writing all of this to try to explain the point of view that > led to this situation in the first place, in revision 1.2 of the > Makefile, four years ago. At that time, the options framework was > not completely finished yet, and users still had to specify WITH_* > and WITHOUT_* variables manually, either on the command line or in > elaborate config files; thus, the autodetection of muine was, indeed, > considered by some to be a useful thing. Now, I think it's outgrown > its usefulness. OK. I totally mis-read the Makefile and got most of my comments wrong. I do hope that ahze will "fix" this so that it behaves as people are most likely to expect it to behave. I will go ahead and update the PR I submitted on this to simply suggest the removal of the "|| exists(${LOCALBASE}/bin/muine". Thanks for you patience in this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751