Date: Tue, 16 Aug 2005 20:51:42 +0200 From: Kirill Ponomarew <krion@voodoo.oberon.net> To: Adam Weinberger <adamw@magnesium.net> Cc: cvs-ports@FreeBSD.org, Kirill Ponomarew <krion@FreeBSD.org>, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/deskutils/gourmet Makefile Message-ID: <20050816185142.GB55949@voodoo.oberon.net> In-Reply-To: <4302300D.5040701@magnesium.net> References: <200508160914.j7G9EiPd061656@repoman.freebsd.org> <4302300D.5040701@magnesium.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 16, 2005 at 02:27:25PM -0400, Adam Weinberger wrote:
> Kirill Ponomarew wrote:
> >krion 2005-08-16 09:14:43 UTC
> >
> > FreeBSD ports repository
> >
> > Modified files:
> > deskutils/gourmet Makefile
> > Log:
> > Fix dependencies and build.
> >
> > Approved by: portmgr (implicit)
>
> This won't fix the build at all. Look at the pre-install: target.
> gourmet requires a python-enabled metakit, and the only way to achieve
> that is to have WITH_METAKIT_PYTHON=yes defined when building metakit.
> All you've accomplished here is ensuring that the port is still BROKEN,
> but in a different way.
>
> Your change may look better from the standpoint of pointyhat logs, but
> in reality, gourmet's dependency is more logically on libmk4py.so than
> on libmk4.so.
I don't know how it would change the functionality of gourmet if
metakit is built without python, but it would make sense to add
NO_PACKAGE into Makefile to prevent cluster from building it until
the problem is resolved. Feel free to add NO_PACKAGE/RESTRICTED if
you know that package will be unusable for users.
> The real issue lies within metakit. There is no python-enabled metakit
> slave port, and one cannot choose to enable python based solely upon
> whether python is already installed (you can only check for
> ${PYTHON_CMD} after bsd.port.pre.mk, but you can only define WITH_PYTHON
> *before* bsd.port.pre.mk... python could really use a WANT_PYTHON switch).
>
> I'd prefer to see this change backed out, but it doesn't make much
> difference either way. In the future, though, could you please run
> changes like this by me first? I recognize that you're doing your
> portmgrial duties here, but surely one of my maintainer-based rights is
> to challenge changes like this *before* they're committed.
Yeah, you're right, sorry for that.
-Kirill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050816185142.GB55949>