Add RPM packaging support

[gchauvet]

Add RPM packaging support

Summary

• Add .cicd/package_rpm.ps1: PowerShell script that stages binaries and Eiffel
  clusters, substitutes spec template placeholders, and invokes rpmbuild
  to produce the packages.
• Add .cicd/rpm/gobo-eiffel.spec: RPM spec template for the main package
  (pre-compiled binaries, runtime config, Eiffel library clusters, profile.d script).
• Add .cicd/rpm/gobo-eiffel-devel.spec: RPM spec template for the devel package
  (Eiffel source code of the tools only).
• Update .gitlab-ci.yml: add a package stage with a package_rpm job that runs
  on release tags matching gobo-YY.MM (or on-demand via
  GOBO_CUSTOM_PIPELINE=package_rpm).

Produced packages

Package	Architecture	Contents
gobo-eiffel-<version>-1.<arch>.rpm	x86_64	Compiled binaries in /usr/bin, runtime config and Eiffel library clusters in /usr/lib/gobo-eiffel, GOBO profile script in /etc/profile.d
gobo-eiffel-devel-<version>-1.noarch.rpm	noarch	Eiffel source code of the tools in /usr/lib/gobo-eiffel/tool

CI trigger rules

• Automatic on git tags of the form gobo-YY.MM[.patch] (e.g. gobo-26.05).
• Manual via pipeline variable GOBO_CUSTOM_PIPELINE=package_rpm.
• Artifacts retained for 90 days.

Test plan

• Trigger the pipeline manually with GOBO_CUSTOM_PIPELINE=package_rpm on a
  branch that has a successful linux_gcc_build_ge job.
• Verify that both .rpm files are produced and available in the pipeline
  artifacts.
• Install gobo-eiffel-<version>.rpm on a Fedora/RHEL system and confirm
  gec --version works, $GOBO is set after opening a new shell, and the
  library clusters are accessible under /usr/lib/gobo-eiffel/library.
• Install gobo-eiffel-devel-<version>.rpm and confirm the tool Eiffel sources
  are present under /usr/lib/gobo-eiffel/tool.

[ebezault]

There are several issues with the PR. The first one is a showstopper for me:

• I understand that under some platforms like Linux, there are some standards where to put the binaries, the libs, etc. However, one nice thing about the Gobo package as it is is that one can use it without having to set any environment variable (not even $GOBO). And one might move it somewhere else (e.g. on a USB key), and it will still work (still no environment variable to be modified in some profile file). This is achieved thanks to the tool executables being able to figure out their location on disk and hence infer the value of $GOBO (because there are supposed to be in $GOBO/bin). The nice functionality will be broken if the executables end up in /usr/bin and the other files in /usr/lib. Note that this technique of being able to use the package without having to set any environment variable has been inspired from the Zig package (https://ziglang.org/), and not surprisingly they don't provide RPM packages which install binaries in different locations.

And then, other issues:

• Not all binary files are included in the RPM. How did you get this list? Did AI generate this list?
• Not all libraries are included in the RPM, and some libraries which are not in Gobo are included (e.g. yaml, json, unicode). How did you get this list? Did AI generate this list?
• I'm not sure there is a real benefit in splitting Gobo into two RPM packages. The source code in $GOBO/tool is not that big. The problem with that split is that we get the binaries, but we don't get the documentation for these tools. And in case of gec the C files and header files needed for the Eiffel compilation are not included in the same RPM package as the binary itself. So we cannot use the Eiffel compiler unless the two RPM packages are installed.
• Gobo packages are not generated from the Gitlab pipeline, but from the Github pipeline. The Gitlab pipeline is only running tests.

[gchauvet]

Thank you for your detailed and fast feedback, it's very helpful.

First, I want to clarify the context of this PR: this is a very early draft. It’s my first time setting up CI and RPM packaging, so I expected quite a few issues. I did use two LLMs to help me get started (which explains some of the inconsistencies in the file lists and the overall roughness).

Originally I was planning to create two packages (gobo-eiffel + gobo-eiffel-devel), inspired by Zig’s packaging model, but I’m perfectly open to shipping just one package if you think it makes more sense for Gobo (and that's exactly what I'm going to do).

Regarding the installation layout, you are absolutely right about the critical issue: putting the binaries in /usr/bin while the rest stays in /usr/lib/gobo-eiffel breaks the very nice zero-configuration feature (automatic $GOBO detection). This is something I will rework to better respect Gobo’s philosophy ; most likely by installing everything under /usr/lib/gobo-eiffel and only creating symlinks in /usr/bin.

In next days, I will also:

• Move the CI to GitHub Actions instead of GitLab CI
• Clean up the file lists properly
• Perhaps add dependencies for the necessary tools (mandatory + optional, including Zig)? We’ll have to see...
• Reconsider the split into two packages (I’m now leaning toward starting with a single package)

I also need to find out how to test the generation of RPMs from my forked repository

I’m happy to follow your guidance on the best approach for the project.
Thanks again for your time and advice!