Re: git: 6a5b2121a0ad - main - graphics/libimagequant: update to 4.0.4

Dima Panov <fluffy@FreeBSD.org> writes:

> On 25.11.2022 20:55, Jan Beich wrote:
>> Dima Panov <fluffy@FreeBSD.org> writes:
>> 
>>> Moreover, hard requirement of rust automagically kills any future to build
>>> huge bunch of packages under emulation, because rust fails under qemu-user-static.
>>> This situation lead to impossibility to have any package depended on graphics/gd
>>> (with IQU enabled) in cross-builded repos.
>> No different from graphics/librsvg2-rust. The package cluster builds
>> aarch64 natively and armv7 emulated on aarch64, so use prebuilt package
>> via "poudriere bulk -b latest".
>
> Nope. It's different -- we have a CHOICE between old librsvg and
> modern librsvg-rust.

librsvg2-rust is an unconditional dependency of many ports while libimagequant is
an optional dependency in few ports (only in one it's unconditional). Either
way user has to take action by adjusting make.conf or disabling port option.

> Hardcoded rust via libimagequant leaves us with no choice at all. Feel
> the difference?

librsvg2 vs. librsvg2-rust split happend back when lang/rust had few
supported architectures. Not because of qemu-user-static which was
always fragile and partially side-stepped via native-xtools.

If you want libimagequant-norust or similar the onus on creating and
supporting that is on you. Beware, security/py-cryptography will also
require lang/rust to build soon (bug 254853).

> And second point -- many advanced users have own poudriere repo to
> build tree with own set of options. In this case prebuilded rust
> often cannot be handled because of different dependency tree.

Port options can be fine-tuned to satisfy poudriere criteria.
lang/rust has few RUN_DEPENDS and mainly used as BUILD_DEPENDS,
so only global stuff like DEFAULT_VERSIONS+=ssl=libressl affecting
ftp/curl may pose a problem.

> Please keep all users avoid of rust buildind burden at least until
> rust issue with emulation will be fixed.

There's currently no consistency how to treat qemu-user-static (e.g.,
librsvg2-rust is default) and requires time to QA workarounds.

Another option is repackaging lang/rust as cross-compiler (similar to
devel/binutils) and hooking into poudriere. Even if qemu-user-static is
fixed build of rust consumers is going to be very slow, like when
non-base Clang is used.