Re: Dependencies on the rust toolchain

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

Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost> writes:

> Given the weight and churn of Rust, I do think we should not blindly 
> upgrade utility libraries to Rusted versions, especially when - as in 
> this case - there is a non-rust alternative.

I share your frustrations about people choosing to use a language that
has a nonportable implementation with vast memory requirements.

However, pkgsrc basically has to track upstreams.  In particular, we
can't stay on non-maintained versions.  An example is ghostsript, which
changed to a license some people were uncomfortable with, and the old
version has become steadily less reasonable to run.

Over time, avoiding rust is more and more tilting at windmills.
Certainly you can, but I just don't see it as viable in general.

You can also set RUST_TYPE=bin.

> I am inclined to make the libimagequant option for graphics/gd 
> non-mandatory.

I don't follow this.  It is an option, and if you want to build without
it, you can set the options variable.  I just did that and it worked
like I expected.  The resulting library does not reference
libimagequant, according to ldd.

If you mean "I would like to change the default", then we'd have to talk
about what upstream gd recommends, what is lost in functionality, and
how to balance that with the concerns of those who decline to deal with
rust.  Without having gone down that path, I really doubt that making it
default off is reasonable.

> And/or package libimagequant v2.

We have a tradition of packaging the last non-rust version, when
somebody cares enough to do it.   See librsvg-c.   I like the "-c"
suffix, as it makes it clearer why it is there.

There is also support for picking the C versions when rust is not
available.

It seems like a reasonable extension to allow a user to set a variable
which means "pretend rust is not available on my platform".