Date: Sat, 06 Aug 2005 20:38:17 +0400 From: Sergey Skvortsov <skv@protey.ru> To: vd@datamax.bg Cc: Adam Weinberger <adamw@magnesium.net>, freebsd-ports@freebsd.org Subject: Re: The right way to depend on a package's extra feature Message-ID: <42F4E779.9030605@protey.ru> In-Reply-To: <20050805073617.GB60681@sinanica.bg.datamax> References: <20050805070513.GA60681@sinanica.bg.datamax> <42F310D2.7020200@magnesium.net> <20050805073617.GB60681@sinanica.bg.datamax>
next in thread | previous in thread | raw e-mail | index | archive | help
Vasil Dimov wrote:
>
> Yes, but I am looking for solution that:
> * does not change the port we depend on (in your case metakit)
> * does not devolve the flow-control to the user saying "I cannot manage
> with this situation, you have to do manually this and this".
Just (c) patch /usr/ports/Mk/* to support:
RUN_DEPENDS=/path/to/check/file:${PORTSDIR}/category/portname:target%WITH_FEATURE_1%FEATURE_2=mydb
or even:
RUN_DEPENDS=/path/to/check/file:${PORTSDIR}/category/portname%WITH_FEATURE_1%FEATURE_2=mydb
(IMO delimiter symbol '%' is aesthetic enough)
In such case dependency should be patched/builded/installed as:
cd category/portname && make WITH_FEATURE_1=yes FEATURE_2=mydb target
Of course, it is not a very trivial patchset. And currently this approach
does not support packages. OPTIONS are not installed with packages - so
there is no possibility/sence to parse them. I think a file like
/var/db/pkg/portname/+FEATURES would be introduced, where OPTIONS is subset
of FEATURES. Exact sematics of FEATURES is fuzzy on the first glance, but we
can draw up a formal specification :)
--
Sergey Skvortsov
mailto: skv@protey.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F4E779.9030605>