Crystal packaging in Fedora

Community
1

I, for one, am a Fedora contributor. I’ve loved Crystal since it’s beginnings and would love to see it as a first class citizen in Fedora.

Up to now, I’ve been using Zawertun’s package as my main crystal driver in Fedora: Making sure you're not a bot!. Kudos to him for maintaining it and doing so in such a great way for so many years.

That said, I’d love to take it into the main repos and have packaging guidelines for it. Every major language has them.

I am a Fedora packager and I would like to know if there is interest in this and, if so, who could help with the packaging process.

This is important. I’ve seen a mini-revival as of late of Crystal within the community. Apps, frameworks and libraries are starting to move again.

We could use that momentum and synergize with Crystal being fully supported in Fedora.

It could bring in more users and make things nicer in general for Crystal.

I’d like to read your opinion.

5 Likes
2

Happy to help with upstream support. I don’t know much about Fedora specifics, though.

2 Likes
3

Don’t worry, I’ve got that covered. I mean, I’ve never introduced a “new” language but I am sure it’s documented somewhere. That’s the good thing about Fedora.

1 Like
4

Hi everyone,

I’m moving the proposal to bring the Crystal Programming Language into the official Fedora and EPEL repositories into its next phase. The initial infrastructure is now functional, and I’m looking for peer review, QA, and collaborators to help refine the implementation before we finalize the FESCo Change Proposal for Fedora 46.

:hammer_and_wrench: The Stack So Far

We’ve built a robust foundation to ensure Crystal packaging is as idiomatic and automated as possible:

  1. cr2rpm: A dedicated Python-based metadata engine and spec generator. It parses shard.yml to drive the build process, similar to rust2rpm or go2rpm. It includes a metadata subcommand for programmatic querying of shard properties.

  2. Standardized RPM Macros: A complete suite (%crystal_setup, %crystal_build, %crystal_install, etc.) that handles:

    • Offline Builds: Automatic detection and handling of vendor tarballs (Source1).
    • Architecture Support: Standardized ExclusiveArch for x86_64 and aarch64.
    • FHS Compliance: Proper placement of binaries and the Crystal standard library.

  3. CI & Validation: The tooling is backed by a pytest suite and passes rpmlint with zero errors/warnings on generated specs.

:microscope: Request for Review & QA

I am looking for “Vibe-Engineers” and packagers to tear this apart and help us find the edge cases:

  • Logic & Architecture: Review the macros.crystal implementation. Is there a more efficient way to handle the bootstrap or the vendor caching?

  • Tooling QA: Run cr2rpm against complex shards (especially those with heavy C-bindings or non-standard directory structures) and report where the spec generation fails or produces non-idiomatic results.

  • EPEL Strategy: Review the epel.rst plan. We need to ensure long-term maintainability given RHEL’s lifecycle.

  • Opinions Welcome: Should we change the naming convention for libraries? Is the %crystal_setup parameterization flexible enough?

:package: Repository & Docs

The entire planning, guidelines, and tooling source is hosted here:
:backhand_index_pointing_right: renich/crystal-in-fedora: Project to take Crystal to Fedora Linux and make it a first-class citizen there. - Codeberg.org

If you’ve ever wanted a first-class Crystal experience on a major enterprise-grade distro, now is the time to weigh in on the foundation.

Looking forward to your PRs, issues, and brutal honesty.

Cheers,

Rénich Bon Ćirić
Fedora Packager

3 Likes
5

I’ve posted this at Fedora’s Discourse: Bringing Crystal to Fedora LInux - Fedora Discussion

2 Likes
6

I took a look at the proposal. It’s a lot of text to ingest, with lots of overlap between the documents. But I suppose that’s the amount of bureaucracy involved with package management for a big distro :person_shrugging:

I started a discussion about dependencies, but apart from that I couldn’t find much where my immediate input could be helpful. Please let me know if there is anything I can do.

2 Likes
7

Fair enough. I will try to condense it. The thing is, I tried to divide it into sections. One thing is submitting a package, another is proposing a policy to package applications and libraries (shards) of that language’s ecosystem and, yet, another is to submit those things to EPEL.

Well kinda. That is, definitely, one way of seeing it and it’s correct. The other perspective is to view it as what it was intended: a procedure engineered by engineers (no pun intended) to try to ensure maximum quality, security and overall maintainability.

I understand. I am grateful and will try assimilate the feedback you’ve provided. Thank you. :slight_smile:

1 Like