(Forgot to include the list on my original reply to Maksim)

That’s great! If you’ve identified things that need to be fixed in the pike source to get things running with GCC 14 (13 is the highest I’m using anywhere), I think we’d love to get patches or a description. That’s something I can assist with getting into the pike tree.

I did experience the annoyance of package names moving around between versions, but it was fairly minor so didn’t come up with a huge plan for dealing with it. JDK was definitely the thorniest problem for me (as it was getting Java support working when I did pkgsrc packages). And GTK2 is going to be a problem going forward; I don’t see much way around it, unless there’s a repo somewhere that makes packages for unloved legacy components, or the pike world decides to make their own.

I think we (well, I at least) would definitely be interested in seeing what you end up with. There’s an opportunity also to include whatever repos you post as members of the pike language org on GitHub, so that it gets a little visibility as a piece of the puzzle.

In a perfect world, pike would be easily available from EL based distros, but being the niche language it is, that’s probably not going to happen, though Debian has it, so maybe not such a dream. At the very least, being able to build good well-thought-out RPMs enables the rest.

Am happy to help as I am able!

Best,

Bill

On Mar 10, 2026, at 7:15 AM, Maksim AbuAjamieh eng.maksim@gmail.com wrote:

Thanks for posting the scripts - the Docker-based approach is exactly the right way to handle reproducible RPM builds, and it's great to have a reference implementation to build on.

I have worked on it and managed to get RPMs for EL9 and EL10 with some effort.

A few things that may be of interest:

EL10 support - I did manage to get EL10 building successfully. But yeah it takes some work: GCC 14's stricter implicit function declaration handling breaks several modules, and a handful of dependencies have been renamed (notably mysql-devel → mariadb-connector-c-devel, pcre-devel → pcre2-devel, and crypt() moving out of glibc into libxcrypt).

I also had to disable the GTK2 module entirely on EL10 as I didn’t want to spend too much time figuring out what the problem was.

The Java dependency problem on EL9 - I hit exactly this. The Java 8 JDK bundles its own internal libzip.so (with an unversioned soname), which rpmbuild's auto-dependency scanner picks up from the Java module and generates a Requires: libzip.so()(64bit) that can't be satisfied by the system libzip package (which ships as libzip.so.5). The fix was to suppress that auto-generated dependency - the JDK itself satisfies it at runtime.

On EL10 with Java 21 the situation is different and an explicit Requires: libzip is the right approach there. Breaking it into a subpackage (as was suggested) is indeed the cleanest way to handle it, which is what I did.

Comments and suggestions are welcome. Happy to publish my work on GitHub if it is useful to anyone.

Thanks again, Maksim