Page MenuHomeFreeBSD

Implement basic flavors
ClosedPublic

Authored by bapt on Apr 8 2017, 9:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 11, 7:31 AM
Unknown Object (File)
Feb 20 2024, 8:33 PM
Unknown Object (File)
Feb 8 2024, 4:15 PM
Unknown Object (File)
Jan 20 2024, 7:41 PM
Unknown Object (File)
Jan 11 2024, 4:04 AM
Unknown Object (File)
Jan 8 2024, 2:41 PM
Unknown Object (File)
Jan 2 2024, 7:17 PM
Unknown Object (File)
Jan 2 2024, 7:17 PM

Details

Summary

To use them:
make FLAVOR=foo

To define a dependency on a flavor
RUN_DEPENDS= something:origin:FLAVOR=foo

Add FLAVORS support to python

Add an example of converting ports to flavor

Will be committed in 3 parts:

  1. The framework part
  2. The python part
  3. The examples

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

So, mmm, the last argument of a _DEPENDS line now has two possible meaning, either the target, or the flavor ?

Mk/Uses/python.mk
311–313 ↗(On Diff #27244)

This should probably be ${PYTHON2_DEFAULT} and ${PYTHON3_DEFAULT}.

In D10327#213866, @mat wrote:

So, mmm, the last argument of a _DEPENDS line now has two possible meaning, either the target, or the flavor ?

yes it can be a target or a variable (in this case FLAVOR) note that something:origin:target:BLA=something works as well

Mk/Uses/python.mk
311–313 ↗(On Diff #27244)

yeah probably, the python2 was a quick and dirty default example

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

This seems to subtly break compatibility between flavoured and non-flavoured ports. Could there not be a default "empty" flavour to support both behaviours? In case of python the default flavour would adhere to DEFAULT_VERSIONS, the flavours would pin the version instead?

devel/py-clint/Makefile
18 ↗(On Diff #27244)

Is this required for the sub-build? would it not be better to pass it through the framework rather than explicitly here?

Also, is something like this thinkable in the future to do a "top down flavour" without adding framework support?

python2_RUN_DEPENDS= etc.

devel/py-clint/Makefile
20 ↗(On Diff #27244)

Actually, this does not need python framework support at all then... or am i missing something?

USES?= python
python2_USES= python:2
python3_USES= python:3

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

There would be no point for a default version. The default flavor is only to make a regular make happening. The package builders should build allow flavors all the time

devel/py-clint/Makefile
18 ↗(On Diff #27244)

The pass through is impossible, my example here is pretty bad because it gives an example where the flavor the port depends on is actually the same as the flavors of this port, but that is not always the case

20 ↗(On Diff #27244)

no the way it has been hooked to python.mk it will work out of box without the requirement of python2_USES

In any case we can't reuse the mechanism of options helpers as we might end with collisions

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

ok. the default changes from DEFAULT_VERSION to default flavour, potentially changing the major version of python, no?

also shouldn't this be [0] ?

devel/py-clint/Makefile
18 ↗(On Diff #27244)

I see, this is for selecting a particular flavour of the dependency, not adding a dependency for the port itself. got it.

20 ↗(On Diff #27244)

understood. still a bit of a bummer, because the use of flavours would be very much flexible with this :)

in any case, great work and thanks for the explanations

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

nope it starts counting a 1 :) [0] would mean [*] meaning the whole values as a single object not as a the first element :)

For the default value, I was puzzled maybe we should not provide a default flavor as it is only design for people calling make directly. Maybe we should add an error saying "a flavor should be specified", Maybe we can do that once the tools have catch up with flavors

devel/py-clint/Makefile
20 ↗(On Diff #27244)

This is a basic first implementation, flexibility will come later along with the complex use cases :)

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

right, [1], sorry :)

So the problem is as follows: someone with his own poudriere bulk run sets DEFAULT_VERSIONS= python=3.4, but this bit of code will break the existing port if you error out or if you build it with the first flavour which is 2.7, not 3.4, any flavour really. it may even override 3.4 as 3.5 if the other flavour is used. That's why I thought having flavours as additional options is more graceful with existing usage: empty flavour handling is automatic and does the right thing that the framework always did.

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

yes I agree with that, the work that have been done by people on the default python is totally wrong, instead they should have worked on flavors or flavors like for such feature, yes when integrated it will be broken. maybe in the specific case of python this can be fixed/workedaround in python.mk.

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

I see, so phasing out version selection by flavour usage? In that case as long as depends show the right version using [1] is ok then.

devel/py-clint/Makefile
20 ↗(On Diff #27244)

Flavors are only shown being used very simply here. If you have a port that has, say, a GNOME and a KDE option, you can do stuff like:

FLAVORS=  gnome kde

.if defined(FLAVOR) && ${FLAVOR:Mgnome}
OPTIONS_SLAVE+=   GNOME
OPTIONS_EXCLUDE+= KDE
.endif
.if defined(FLAVOR) && ${FLAVOR:Mkde}
OPTIONS_SLAVE+=   GNOME
OPTIONS_EXCLUDE+= KDE
.endif

Which is a bit awful, so we may end up adding options helpers to set options depending on the flavor being used.

antoine added inline comments.
Mk/bsd.port.mk
1071 ↗(On Diff #27244)

The following ports define FLAVOR without defining FLAVORS: x11-themes/*-aluminumalloy-*-theme

I had a basic patch for Poudriere to use DEPENDS_ARGS, which was just 1 step away from supporting FLAVORS as well. What was lacking was optimizing it for bulk -a. After recent refactoring of Poudriere's dependency lookup, it should work much better. I will resume working on this soon.

devel/py-clint/Makefile
18 ↗(On Diff #27244)

This FLAVOR= thing is not needed in *this case*. This is what DEPENDS_ARGS is used for and the python framework already does this.
python.mk:

.if !defined(PYTHON_NO_DEPENDS)
DEPENDS_ARGS+=          PYTHON_VERSION=${PYTHON_VERSION}
.endif

So when you build py-lint with make arg FLAVOR=python3, it will pass DEPENDS_ARGS=PYTHON_VERSION=python3 down to all dependencies.

I have a basic PoC patch for Poudriere to handle FLAVORS already that did not need this FLAVOR argument.

Note I said "*this case*". It is certainly possible and useful to depend on a specific FLAVOR for a package. But in this case it is superfluous.

Also note that this last argument here passing FLAVOR=foo down to a dependency *will also still* pass DEPENDS_ARGS values and may cause odd conflict and confusion, which is why I suggest we don't use it in this FLAVOR=${FLAVOR} method, rather than more explicit FLAVOR=explicit_flavor.

I would like to remove the DEPENDS_ARGS+=PYTHON_VERSION=${PYTHON_VERSION} , it regularly breaks installing from ports some ports that depend on both python2 and python3 (gnome for instance) and the PYTHON_VERSION variable is polluting the build of autotools based ports.

I would like to remove the DEPENDS_ARGS+=PYTHON_VERSION=${PYTHON_VERSION} , it regularly breaks installing from ports some ports that depend on both python2 and python3 (gnome for instance) and the PYTHON_VERSION variable is polluting the build of autotools based ports.

Breaks where? If poudriere, then expected since it has no support yet.

I would like to remove the DEPENDS_ARGS+=PYTHON_VERSION=${PYTHON_VERSION} , it regularly breaks installing from ports some ports that depend on both python2 and python3 (gnome for instance) and the PYTHON_VERSION variable is polluting the build of autotools based ports.

Breaks where? If poudriere, then expected since it has no support yet.

Breaks when installing from ports.

This revision is now accepted and ready to land.May 23 2017, 6:54 PM
This revision now requires review to proceed.May 23 2017, 6:55 PM

Meh, accepted in the wrong browser window :(

We need a standard syntax for specifying an origin with a specific FLAVOR for display and tool purposes. Consider something like 'portmaster devel/py-flake@py33'.
I've been using '@' in Poudriere so far but I am open to anything that is unique from origins - something no origin is expected to have. And that can be stored as a filename (yes the / is an issue there already but I work around that one).
The depends lines here use 'devel/py-flake:FLAVOR=py33'. I think it would be simpler to use this standard CLI/Display syntax in the depends lines as well. Using : may be problematic since we already use that to separate out the fields in the dependency list and in the case of FLAVOR it is a critical part of the origin that identifies a unique package. For Poudriere I've been calling this the "origin spec". So I don't like the idea of using :. I'm not married to @ but am proposing it for now. So something like:

RUN_DEPENDS=        ${PYTHON_PKGNAMEPREFIX}args>=0.1.0:devel/py-args@${FLAVOR}

We need a standard syntax for specifying an origin with a specific FLAVOR for display and tool purposes. Consider something like 'portmaster devel/py-flake@py33'.
I've been using '@' in Poudriere so far but I am open to anything that is unique from origins - something no origin is expected to have. And that can be stored as a filename (yes the / is an issue there already but I work around that one).
The depends lines here use 'devel/py-flake:FLAVOR=py33'. I think it would be simpler to use this standard CLI/Display syntax in the depends lines as well. Using : may be problematic since we already use that to separate out the fields in the dependency list and in the case of FLAVOR it is a critical part of the origin that identifies a unique package. For Poudriere I've been calling this the "origin spec". So I don't like the idea of using :. I'm not married to @ but am proposing it for now. So something like:

RUN_DEPENDS=        ${PYTHON_PKGNAMEPREFIX}args>=0.1.0:devel/py-args@${FLAVOR}

Also, it may be argued that we should use : to retain compatibility with tools that don't know about FLAVORS, so they still build the origin. I think this argument is not valid since the tool would end up building *the wrong package/flavor*. So the tool should rightly break if it doesn't support FLAVORS.
I strongly support FLAVORS, so I am willing to put the energy into updating tools that need the support if there is actual demand for the tool.

FYI I added a PACKAGE_BUILDING_FLAVORS export from Poudriere and am using it, a bit prematurely but it's better than renaming it when this is committed, in rP442592.

xmj added inline comments.
Mk/bsd.port.mk
1078 ↗(On Diff #27244)

This problem isn't just affecting python. Suppose you introduce flavors to rubygems and want to set DEFAULT_VERSIONS+= ruby=2.4 - while ports might generally define FLAVORS= ruby22 ruby23 ruby24.

Wouldn't it be possible to unite flavors and default versions - such that you define flavors like FLAVORS=python2.7 python3.5 (if something doesn't like 3.3 / 3.4) or similarly FLAVORS= ruby2.2 ruby2.3 ruby2.4,

and Mk/bsd.default-versions.mk picks this up to automatically prefer the correct flavor?

Mk/bsd.port.mk
1078 ↗(On Diff #27244)

The following patch fixes the above problem -- tested for python2/3 and with a slight extention to showcase ruby.

diff --git a/Mk/bsd.default-versions.mk b/Mk/bsd.default-versions.mk
index f84b898348fd..051e61b09cd8 100644
--- a/Mk/bsd.default-versions.mk
+++ b/Mk/bsd.default-versions.mk
@@ -143,4 +143,16 @@ VARNISH_DEFAULT?=	4
 # Version of lang/gcc.  Do not override!
 LANG_GCC_IS=		5
 
+.for lang in APACHE BDB FIREBIRD FPC GCC GHOSTSCRIPT LINUX LUA MYSQL PERL5 \
+	PGSQL PHP PYTHON PYTHON2 PYTHON3 RUBY SSL TCLTK
+.if defined(${lang}_DEFAULT)
+.if ${_l} == "python"
+# XXX: I'm not sure if python things should be flavored for each version?
+${_l:tu}_FLAVOR=	${lang:C/=.*//g}${${_l:tu}_DEFAULT:C/\..*//g}
+.else
+${lang:tu}_FLAVOR=	${lang:tl}${${lang:tu}_DEFAULT:C/\.//g}
+.endif
+.endif
+.endfor
+
 .endif
diff --git a/Mk/bsd.port.mk b/Mk/bsd.port.mk
index d7268d3ad83e..361657b054f1 100644
--- a/Mk/bsd.port.mk
+++ b/Mk/bsd.port.mk
@@ -1066,21 +1066,6 @@ _PORTS_DIRECTORIES+=	${PKG_DBDIR} ${PREFIX} ${WRKDIR} ${EXTRACT_WRKDIR} \
 
 .include "${PORTSDIR}/Mk/bsd.commands.mk"
 
-.if !empty(FLAVOR)
-.  if empty(FLAVORS)
-IGNORE=	FLAVOR is defined while this port does not have FLAVORS.
-.  elif ! ${FLAVORS:M${FLAVOR}}
-IGNORE=	Unknown flavor '${FLAVOR}', possible flavors: ${FLAVORS}.
-.  endif
-.endif
-
-.if !empty(FLAVORS) && empty(FLAVOR)
-FLAVOR=	${FLAVORS:[1]}
-.endif
-
-# Do not leak flavors to childs make
-.MAKEOVERRIDES:=	${MAKEOVERRIDES:NFLAVOR=*}
-
 .if defined(CROSS_TOOLCHAIN)
 .if !defined(.PARSEDIR)
 IGNORE=	Cross building can only be done when using bmake(1) as make(1)
@@ -1294,6 +1279,32 @@ WITH_DEBUG=	yes
 .endif
 
 .include "${PORTSDIR}/Mk/bsd.default-versions.mk"
+
+.if !empty(FLAVOR)
+.  if empty(FLAVORS)
+IGNORE=	FLAVOR is defined while this port does not have FLAVORS.
+.  elif ! ${FLAVORS:M${FLAVOR}}
+IGNORE=	Unknown flavor '${FLAVOR}', possible flavors: ${FLAVORS}.
+.  endif
+.endif
+
+.if !empty(FLAVORS) && empty(FLAVOR)
+FLAVOR_TYPE= ${FLAVORS:[1]:C/[0-9\.]*//g}
+PREFERRED_FLAVOR=		${${FLAVOR_TYPE:tu}_FLAVOR}
+
+# check if the desired flavor is in flavors at all
+.for flavor in ${FLAVORS}
+.if ${flavor} == ${PREFERRED_FLAVOR}
+FLAVOR=	${PREFERRED_FLAVOR}
+.endif
+.endfor
+# if not, default to first flavor mentioned.
+FLAVOR?=	${FLAVORS:[1]}
+.endif
+
+# Do not leak flavors to childs make
+.MAKEOVERRIDES:=	${MAKEOVERRIDES:NFLAVOR=*}
+
 .include "${PORTSDIR}/Mk/bsd.options.mk"
 
 .endif
diff --git a/ports-mgmt/create-rb-port/Makefile b/ports-mgmt/create-rb-port/Makefile
index 0bf6f9789c65..c4139010ca84 100644
--- a/ports-mgmt/create-rb-port/Makefile
+++ b/ports-mgmt/create-rb-port/Makefile
@@ -7,7 +7,9 @@ CATEGORIES=	ports-mgmt
 MAINTAINER=	swills@FreeBSD.org
 COMMENT=	Script to ease creation of rubygem- ports
 
-RUN_DEPENDS=	gem:devel/ruby-gems
+RUN_DEPENDS=	gem:devel/ruby-gems@${FLAVOR}
+
+FLAVORS=	ruby22 ruby23 ruby24
 
 USE_GITHUB=	yes
 GH_ACCOUNT=	swills
bdrewery requested changes to this revision.Jun 7 2017, 6:57 PM
bdrewery added inline comments.
Mk/bsd.port.mk
3726 ↗(On Diff #27244)

Please only loop if empty(FLAVOR) otherwise only clean for the provided FLAVOR.

This revision now requires changes to proceed.Jun 7 2017, 6:57 PM
Mk/bsd.port.mk
1058 ↗(On Diff #27244)

Adding in a random place.

Please also add a PKG_NOTE for what FLAVOR is set to in the package. This is likely going to be needed for things like portmaster to support flavors.

Some thing we need to do (which I will soon move to a FlavorsTODO wiki)

Before commit:

  1. Fix this patch to support the *:ORIGIN@FLAVOR dependency line syntax (many of the *-depends targets don't know how to handle that)
  2. Decide on a sub-package dependency line syntax to ensure it does not conflict with origin@FLAVOR
  3. Announce intentions to community (first 2 items need solved first because people will want to test and see a working patch)
  4. Make a wiki page for FLAVORS design (needed for tools developers)
  5. Figure out how OPTIONS + FLAVORS work. Meaning if we make bash-static into a FLAVOR, how do I change the OPTIONS only for FLAVOR=static *as a user*? I can do that now, but it's not possible with this patch. We need to modify the OPTIONSFILE (sp?) to include FLAVOR and do something about make config, etc. This is also likely a lacking feature in Poudriere to properly these options.
  6. PORTS_FEATURES+=FLAVORS
  7. PKG_NOTES support (see comments)

Anytime:

  1. Make a wiki page for FLAVORS conversion (like the STAGEDIR one)
  2. Document that FLAVORS may need to define CONFLICTS on each others PKGNAMES if they conflict with each other
  3. Portsmon / Freshports support
  4. Decide if MOVED should support @FLAVOR syntax. I think it should since we'll want to do things like move shells/bash-static to shells/bash@static. (Poudriere will have implicit support for this)
  5. Document that each FLAVOR must have a unique PKGNAME
  6. Make qa or sanity-check enforce that each FLAVOR has a unique PKGNAME
  7. Make helpers -- not sure on specifics -- but at least one for CONFLICTS -- probably one for easily mapping directly to one or more options in OPTIONS_DEFINE and making them default
  8. Document some policy on NOT effectively doing FLAVORS=${OPTIONS_DEFINE} - this will be highly subjective as to what is acceptable and not but is why we have the 6 month window to come up with this policy
  9. Enforce in sanity-check that _DEPENDS_ARGS_ and _FLAVOR_ are not both defined (this is a saving grace for things like Poudriere to not blow up wildly)
Mk/bsd.port.mk
1058 ↗(On Diff #27244)
Index: bsd.port.mk
===================================================================
--- bsd.port.mk (revision 443065)
+++ bsd.port.mk (working copy)
@@ -1499,6 +1502,11 @@ PKG_NOTES+=      expiration_date
 PKG_NOTE_expiration_date=      ${EXPIRATION_DATE}
 .endif

+.if defined(FLAVOR)
+PKG_NOTES+=    flavor
+PKG_NOTES_flavor=      ${FLAVOR}
+.endif
+
 TEST_ARGS?=            ${MAKE_ARGS}
 TEST_ENV?=             ${MAKE_ENV}
Mk/bsd.port.mk
1058 ↗(On Diff #27244)

Woops should be !empty(FLAVOR) and PKG_NOTE_flavor (not PKG_NOTES_flavor)

Mk/bsd.port.mk
1057 ↗(On Diff #27244)

Please also add PORTS_FEATURES+= FLAVORS. This will allow me to remove checks on DEPENDS_ARGS in Poudriere.

FYI Poudriere git master now has FLAVORS support. You'll need the PORTS_FEATURES+= FLAVORS and the do-depends.sh change I showed here.

Mk/Scripts/do-depends.sh
126 ↗(On Diff #27244)

Here is what I used for testing poudriere with @ syntax:

Index: Mk/Scripts/do-depends.sh
===================================================================
--- Mk/Scripts/do-depends.sh    (revision 443065)
+++ Mk/Scripts/do-depends.sh    (working copy)
@@ -126,6 +126,16 @@ for _line in ${dp_RAWDEPENDS} ; do
        *) origin="${PORTSDIR}/${origin}" ;;
        esac

+       case "${origin}" in
+       *@*)
+               flavor="${origin#*@}"
+               origin="${origin%@*}"
+               export FLAVOR=${flavor}
+               echo "Fixed origin to ${origin} and flavor to ${flavor}" >&2
+               ;;
+       *) ;;
+       esac
+
        depends_args="${dp_DEPENDS_ARGS}"
        target=${dp_DEPENDS_TARGET}
        if [ -n "${last}" ]; then
Mk/Uses/python.mk
316–322 ↗(On Diff #27244)

Something I just realized for our conversions, USES= python:* will let us add a FLAVORS= directly in python.mk. Most python ports use of USES defines which python versions it supports. Thus we know which FLAVORS to advertise directly from python.mk. This should speed up the initial conversion tremendously, and hell I'm half-tempted to just do it right now to stop dealing with DEPENDS_ARGS in Poudriere.

bapt edited edge metadata.
  • Change the syntax for flavor dependencies so that it becomes
  • Fixes regarding origin@ handling
  • Make clean message FLAVOR aware
  • Rework the clean target to handle flavor and non flavors
  • Add PORTS_FEATURES
  • Add an annotation to specify the flavor
bapt marked 6 inline comments as done.EditedJul 14 2017, 2:10 PM
This comment has been deleted.
Mk/bsd.port.mk
1078 ↗(On Diff #27244)

I really disagree on having flavours for all versions of ruby for now. and this change can be done later if really needed.

Mk/Uses/python.mk
316–322 ↗(On Diff #27244)

FLAVOR will be defined too late in that case

antoine requested changes to this revision.Aug 2 2017, 8:37 AM

This breaks make index

make_index: /usr/ports/devel/py-clint: no entry for /usr/ports/devel/py-args@python2

This revision now requires changes to proceed.Aug 2 2017, 8:37 AM

This breaks make index

make_index: /usr/ports/devel/py-clint: no entry for /usr/ports/devel/py-args@python2

Adding some @ somewhere in this part of Mk/bsd.port.mk may help

_EXTRACT_DEPENDS=${EXTRACT_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
_PATCH_DEPENDS=${PATCH_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
_FETCH_DEPENDS=${FETCH_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
_LIB_DEPENDS=${LIB_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
_BUILD_DEPENDS=${BUILD_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}
_RUN_DEPENDS=${RUN_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}

This breaks make index

make_index: /usr/ports/devel/py-clint: no entry for /usr/ports/devel/py-args@python2

This fixes the issue for me:

--- Mk/bsd.port.mk.patched      2017-07-31 16:53:43.492857000 +0000
+++ Mk/bsd.port.mk      2017-08-03 08:35:05.637010000 +0000
@@ -4265,12 +4265,12 @@
 # first to avoid gratuitous breakage.

 . if !target(describe)
-_EXTRACT_DEPENDS=${EXTRACT_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
-_PATCH_DEPENDS=${PATCH_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
-_FETCH_DEPENDS=${FETCH_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
-_LIB_DEPENDS=${LIB_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
-_BUILD_DEPENDS=${BUILD_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}
-_RUN_DEPENDS=${RUN_DEPENDS:C/^[^ :]+:([^ :]+)(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}
+_EXTRACT_DEPENDS=${EXTRACT_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
+_PATCH_DEPENDS=${PATCH_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
+_FETCH_DEPENDS=${FETCH_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
+_LIB_DEPENDS=${LIB_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,}
+_BUILD_DEPENDS=${BUILD_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}
+_RUN_DEPENDS=${RUN_DEPENDS:C/^[^ :]+:([^ :@]+)(@[^ :]+)?(:[^ :]+)?/\1/:O:u:C,(^[^/]),${PORTSDIR}/\1,} ${_LIB_DEPENDS}
 . if exists(${DESCR})
 _DESCR=${DESCR}
 . else

Before this goes in, we need helpers for pkgnameprefix/suffix, and conflicts* because while the python ports take care of it, other ports will not.

Mmmm, maybe not before, as we just want this to go in and not be used at first

This revision was automatically updated to reflect the committed changes.