Re: port-amd64/54862: lang/rust is dependcy for fvwm in pkgsrc - Why!?

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/54862; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-amd64/54862: lang/rust is dependcy for fvwm in pkgsrc -
 Why!?
Date: Wed, 15 Jan 2020 18:00:16 +0000

 On Wed, Jan 15, 2020 at 05:00:00PM +0000, supersafh%gmail.com@localhost wrote:
  > I´ve noticed that from NetBSD 8.1, a programming language called
  > rust is present in pkgsrc. This packages seem to be a standard
  > dependency for a large number of other packages in pkgsrc. May I
  > ask why? For instance: I want to compile wm/fvwm and lang/rust is
  > being referenced as a dependency which causes the build to switch
  > to this package! Besides it seeming huge and take forever to
  > compile (not to mention it fails to build at all on my system), but
  > why would I want a programming language installed with my window
  > manager!!!??? This makes NO sense. I humbly request it be removed
  > as a standard dependency in pkgsrc and only referenced if so
  > specified in the build.
 
 In the case of fvwm, it's because it has recently started using
 librsvg, whose upstream has decided for some reason to rewrite in
 rust.
 
 Your immediate options are:
 
 (1) set LIBRSVG_TYPE in mk.conf to use the old (but now unmaintained)
 librsvg written in C;
 
 (2) figure out how to make fvwm's usage of librsvg optional, then turn
 the option off;
 
 (3) revert to an older fvwm package;
 
 (4) suck it up.
 
 
 In the long term, you can:
 
 (1) take up maintenance of the C version of librsvg or persuade
 someone else to;
 
 (2) campaign against the use of librsvg;
 
 (3a) take up maintenance of the C version of librsvg (or persuade
 someone to);
 
 (3b) convince librsvg upstream that they were wrong and should go back
 to C, or forward to something else, and fight off the RESF (good luck
 with that);
 
 (4) suck it up.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost