On Tue, Aug 25, 2009 at 04:15:51PM -0700, Kevin Oberman wrote: > > Date: Wed, 26 Aug 2009 01:50:01 +0300 > > From: Peter Pentchev <r...@ringlet.net> > > > > On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote: > > > I have been trying to remove all dependencies on the broken muine port > > > and discovered that an error in the serpentine port Makefile causes > > > serpentine to always depend on muine. > > > > > > The Makefile uses the config option MUINE to indicate whether to build > > > the muine plugin, but the script then checks "WITH_MUINE" and always > > > build the muine plugin and creates a dependency on muine. > > > > > > I have opened PR ports/138179. > > > > > > I patched the Makefile with: > > > --- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.000000000 > > > -0700 > > > +++ sysutils/serpentine/Makefile 2009-08-25 10:07:00.000000000 -0700 > > > @@ -29,7 +29,7 @@ > > > > > > .include <bsd.port.pre.mk> > > > > > > -.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine)) && > > > ${ARCH}=="i386" > > > +.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386" > > > BUILD_DEPENDS+= muine:${PORTSDIR}/audio/muine > > > RUN_DEPENDS+= muine:${PORTSDIR}/audio/muine > > > PLIST_SUB+= MUINE="" > > > > Errrr... > > > > I strongly doubt that this is the reason for your problems. > > > > Actually, this is exactly how the Ports Collection's "options" framework > > is supposed to work: the OPTIONS variable lists just the names of > > the options, then bsd.port.mk prompts the user through a dialog > > (or just uses the options' default values) and sets either WITH_name > > or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name, > > just as it does in this case. The option is named "MUINE", but > > the bsd.port.mk framework will set "WITH_MUINE" if the user wants it, > > or WITHOUT_MUINE if she doesn't (or building in batch mode, since > > the option defaults to Off). > > > > So the Makefile check is actually correct. > > > > I find it a little bit hard to believe that it is exactly this change > > to the Makefile that helped you get a serpentine build without muine. > > Could it be that, in the meantime, you had also removed the muine > > port itself? The Makefile check will be satisfied if the MUINE option > > is enabled *or* if the "muine" executable is present in /usr/local/bin. > > This is most probably because the serpentine configure script looks for > > muine itself and uses it unconditionally if it finds it. > > > > So... maybe you just had a /usr/local/bin/muine, and that made > > the serpentine port always build with it? Because the Makefile check > > is actually correct as per the ports options framework :/ > > Ack. You are correct. > > 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" > > As a result, you can't deinstall muine as serpentine depends on it, but > you can't build serpentine without a dependency on muine until you > deinstall muine. I am confused as to the whole point of this structure. > If muine is installed, serpentine will be built with the plugin...end of > story. The configuration option does nothing. The only effect it has is > to force the installation of muine on the initial install muine is not > already installed.
This structure is probably targeted at the case of the port being built on a clean system (or at least a clean-ish system). From your explanations, it seems to me that you are considering the case of the port being built while a previous version of serpentine is still installed on the system. While this is, indeed, convenient, and maybe it is the way it's done by some port building helper tools, IMHO it's a bit risky: I always prefer to build ports without having another instance of the port installed to avoid the danger of the port picking up some of "its own" pieces from the older, currently installed version. I've had trouble in the past with ftp/curl - for some reason or other, the test suite sometimes picked up the libcurl.so from /usr/local/lib/ and not the one it was *supposed* to use (its own, in its own build directory) - thus the tests for *newer* features failed. There could be other ways in which this could pose problems. Of course, this is merely my humble opinion, and I do realize the convenience of still having the port installed while you build its newer version - the old-fashioned way I do things leaves me X-less and Firefox-less for hours at a time on big upgrades :) Still, I'm saying this in the hope that you will see the case that the port maintainer had in mind when writing the Makefile :) (it's valid for the automated package build systems, too) > I guess the right way is to change the statement to read: > .if defined(MUINE) && ${ARCH}=="i386" "MUINE" is never defined, or at least not by the Ports Options framework. It's either WITH_MUINE or nothing. In this particular case, removing the check could work. In my previous message I mentioned the possibility of serpentine unconditionally using muine if found; from a quick look at the serpentine's configure script, it doesn't do that. I've known pieces of software that do (yes, gtkpod, I'm looking at you now, with a malicious gleam in my eye). > Or, since muine looks to be dead, just rip out the muine stuff. I believe that's for the maintainer to decide :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@space.bg r...@freebsd.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation.
pgpS7VV5mOQvL.pgp
Description: PGP signature