Re: librsvg as tool dependency and LIBRSVG_USE_RUST

[Greg Troxel <gdt%lexort.com@localhost>]

Leonardo Taccari <leot%NetBSD.org@localhost> writes:

> after the move of graphics/librsvg to graphics/librsvg-c and
> introduction of LIBRSVG_USE_RUST it is no longer possible to honor
> user's LIBRSVG_USE_RUST=no preference when librsvg is picked up via
> BUILD_DEPENDS or TOOL_DEPENDS (e.g. graphics/adwaita-icon-theme).

Stepping way back, I think that LIBRSVG_USE_RUST is not really the right
variable name and mental model here.   Really, we have two
implementations of librsvg.  Yes, that's because one of them uses rust,
but from the point of view of the pkgsrc machinery, that's not
important.  What is important is that on any given system, there is a
choice of which to use.  This is much like FOO_TYPE for various kinds of
FOO, with the likelihood of FOO_PREFERRED and FOO_ACCEPTED.

> I would like to propose the following patch that address these problems
> by introducing:
>
>  - graphics/librsvg/available.mk: that just define LIBRSVG_USE_RUST (so
>    devel/pango, fonts/harfbuzz, misc/libreoffice or any other package
>    can just include it to check what is the preferred librsvg
>    implementation to be used)
>  - graphics/librsvg/tool.mk: that adds librsvg as a tool dependency by
>    honoring LIBRSVG_USE_RUST user's preference.  In that way packages
>    that needs librsvg instead of directly TOOL_DEPENDS will need to
>    include graphics/librsvg/tool.mk.

Is this really TOOL_DEPENDS, so that it's used only at build time?

I'd like to see this as either mk/librsvg.mk, or
graphics/librsvg/librsvg.mk, that one includes to get a dependency, with
perhaps a variable to declare which kind.  Basically lining up with
/usr/pkgsrc/mk/foo.*mk for many values of foo.

So basically, I agree in concept, but would like to remove the "this is
about rust" from the interface and just have it be "which librsvg
implementation should we use on this system" (even if it is driven by rust).