On 2023/07/01 17:02, Volker Schlecht wrote:
> .if ${CONFIGURE_STYLE} == "rebar3"
> -MODERL_BUILD_DEPENDS += devel/rebar3
> +MODERL_BUILD_DEPENDS += rebar3-*-${_MODERL_FLAVOR}:devel/rebar3
You'll need to specify the flavour for the dependency, i.e. instead of
devel/rebar3, use :devel/rebar3,${_MODERL_FLAVOR}, so that ports uses
the correct flavour when automatically building rebar3 as a BDEP.
> RCS file: /cvs/ports/devel/rebar3/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- pkg/PLIST 16 Jan 2023 18:21:24 -0000 1.3
> +++ pkg/PLIST 1 Jul 2023 14:20:34 -0000
> @@ -1,2 +1,4 @@
> @pkgpath devel/rebar
> -bin/rebar3-${ERL_VERSION}
> +@conflict rebar3-*-erlang{$MODERL_VERSION}<${V}
> +@option no-default-conflict
> +bin/rebar3-${MODERL_VERSION}
It is possible to do this along these lines (though I think this
particular conflict is a bit wrong), but I think it will get awkward
later with updates.
Instead I think you should override FULLPKGNAME, similar to how it
works with Python ports that have both 2.7 and 3.x versions (e.g. like
py-yaml). So you would have packages named erl25-rebar3 and erl26-rebar3
which don't conflict with each other anyway. Then you don't have
complicated @conflict/@option constructs because the defaults will work.
You'll need "quirks renames" ($stem_extensions table) to handle moves
of existing ports (e.g. rebar3-*-erlang25 -> erl25-rebar3, etc). For
this you will need to conflict with the _old_ names but they'll be
static and won't be an ongoing pain for future updates.
Easiest way to handle those conflicts is by having the module
generat a variable that expands to the conflict line you need
(@conflict rebar3-*-erlang25 or @conflict rebar3-*-erlang26 as
appropriate), adding that var to SUBST_VARS, and manually adding that
(say ${MODERL_CONFLICT}) to plists where needed.
(+ any ports with a run/lib dependency on a port which got renamed
in that way, or which changed pkgpath i.e. dir/port -> dir/port,flavor,
will need a bump).
No comments:
Post a Comment