Re: librsvg

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

Thomas Klausner <wiz%NetBSD.org@localhost> writes:

> librsvg has a number of users (see attachment) and rust is not ported
> to all pkgsrc platforms. If I read rust's Makefile correctly, it
> supports macOS, Linux, SunOS, FreeBSD, some NetBSD versions/ports.
>
> We currently have librsvg 2.40.20 in pkgsrc, which is the last version
> that is C-only. It was last updated in 2017, I don't expect further
> updates.
>
> Do we just forget about the C version?

I don't think that's even close to reasonable, unless it's ok to remove
librsvg as a dependency for everything that depends on it, both in terms
of having it still build, and in terms of not losing functionality.
(Really, it's not reasonable of any package that ought to be portable to
be implemented in a way where it can't run on many systems, and arguably
unreasonabel even to need hours of CPU time on systems that are newer
than retrocomputing.  I just looked, and a mac notebook barely 10 years
old took 10 hours to build rust.  But that issue is not our call.)

> Or should we make librsvg-c and librsvg-rust and make libsrv/bl3.mk
> include one or the other based on the platform?

Yes, and as others have said make an option so that people who want to
avoid rust can.  Perhaps librsvg-c as a new package and make librsvg be
the rust version.

I realize this sets us up for the "two ghostscripts" problem, but the
world may change before then.  Maybe rust will become a reasonable
thing, perhaps implemented by clang and gcc.



Q2 is coming.  I don't know if you are intending to do this now vs after
the branch.  It's not clear to me that this change meets the criterion
that it's expected that all fallout on all platforms will be fixed by
branch start, but OTOH if it's a matter of a .if to default on the
option to use the -c version, then it seems easy to just adjust the .if
in case of trouble, so the risk is small.
s