From: Marek Szuba <marecki@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
Date: Fri, 27 Oct 2023 12:52:41 +0100 [thread overview]
Message-ID: <07973eb2-2f26-4086-991e-633f2fe4e8f6@gentoo.org> (raw)
In-Reply-To: <dcc60ca4-5f13-45b9-9c18-8fca8220ad6e@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3247 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-10-27 11:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 1:00 [gentoo-dev] Last rites: media-gfx/gmic Marek Szuba
2023-10-26 1:29 ` [gentoo-dev] " Jonas Stein
2023-10-26 3:41 ` Eli Schwartz
2023-10-27 11:52 ` Marek Szuba [this message]
2023-10-27 11:24 ` Marek Szuba
2023-10-31 6:50 ` Zoltan Puskas
2023-10-31 7:05 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07973eb2-2f26-4086-991e-633f2fe4e8f6@gentoo.org \
--to=marecki@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox