On 2023-10-26 04:41, Eli Schwartz wrote:

> This is of course either untrue or every kind of over-reaction, and 
> users have commented there to the effect of being willing to help
> sort things out but there has been radio silence.

...which, sadly, has been my _overall_ experience with G'MIC upstream.

> I think this also offers some compelling arguments against
> maintainers being willing to  deal with the challenges of this
> software -- this is a pretty steep social cost to investing time and
> effort into caring about, using, or maintaining such software.

Given where this package has come from, I have got a nagging feeling
that its maintainers suffer from a problem that is fairly common among
computational scientists (and before anyone gets offended, a quick
reminder that I myself am in fact a computational scientist... Plus just
have a look at what many sci-* ebuilds have to look like) - namely that
however brilliant they might be at devising algorithms, they are rather
less adept at developing actual software.

Consider some of the issues I have come up against while maintaining 
this package (disclaimer: I haven't checked if any of these have been 
fixed in Git since the release of 3.3.1:

  - the reason for the megapatch, i.e. features being enabled 
automagically depending on the presence/absence of dependencies at build 
time. Not that big of a problem for end-users but very much 
distro-unfriendly;

  - one of the alleged reasons for G'MIC upstream to have switched from 
CMake to a hand-crafted Makefile (and one which said Makefile still 
fails to fix), namely building without X11 support. Given all that is 
needed to address the issue is something along the lines of "if !X11 
CFLAGS+=-Dcimg_display=0", I simply do not understand why this remains open;

- the use of RPATH="." with shared libraries in spite of it being widely 
considered a security risk, and apparently without any actual reason 
(media-gfx/gmic appears to work perfectly well with the relevant linker 
flag patched out);

- the use of backslash-whitespace construct in the hand-crafted Makefile 
causes build issues on systems with grep 3.8 or newer. For the record, 
GNU grep-3.8 was released over a year ago and Gentoo is now on 3.11;

- downright broken target dependency chains, even with -j1 (that bit 
falls under "if anything, the handcrafted Makefile has got worse since 
its introduction");

- a rather quirky way of locating the GIMP plug-in directory, including 
attempting to write to that directory when it hasn't been located - or 
even when the GIMP plug-in is not to be built.

I rest my case.

> Marecki -- is there any specific concern that it's likely to rot
> quickly if it lacks a maintainer?

The megapatch has to be updated on a fairly regular basis so at the very 
least, we would end up without updates. On top of that we have got the 
usual problems cropping up every time we add a new gcc/clang version, 
having to support MUSL (let's be honest, even among the more mature 
projects testing against non-glibc is rare), slibtool... So yes, I 
consider media-gfx/gmic very likely to rot quickly without continuous 
maintenance.

-- 
Marecki