serpentine port forces dependency on muine

[Kevin Oberman]

> Date: Thu, 27 Aug 2009 02:10:06 +0300
> From: Peter Pentchev <roam at ringlet.net>
> 
> 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 <m.seaman at infracaninophile.co.uk>
> > > 
> > > 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 at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751