On 5/12/26 7:59 PM, Charles Oliver Nutter wrote:
> On Tue, May 12, 2026 at 12:43 PM Fabio Valentini
> <decathorpe(a)gmail.com> wrote:
>
> I think just "unpacking a tarball" won't be appropriate for an
> official package, assuming that this includes pre-built JAR files?
> Those would all need to get built from source during the package
> build, but this should be a solveable problem. More concrete feedback
> will probably happen once you can share a working package / RPM spec
> file and / or submit that for package review.
>
For some context for approaching packaging JRuby itself (meaning engine
sans bundled gems) FTR there are guidelines that must be upheld for
packages (unless exception is given by FESCo). Since JRuby is mainly
Java, in addition to general guidelines [0], the Java guidelines [1]
could apply, similarly to how C guidelines apply to CRuby.
> Oh sure, I understand that. I just provide the example of "unpacking"
> to show that there's not much as far as native dependencies required
> once a JDK is available.
>
> JRuby itself is published to Maven, of course, but the "dist" package
> most people install is distributed as a a tarball or zip containing:
>
> * pre-built jar(s) for JRuby itself
> * a set of bin scripts to launch JRuby and provided tools
> * a whole bunch of Ruby sources and additional jar files to provide
> the Ruby standard library (most of the pure-Ruby is the same code as
> in standard Ruby).
Pure-Ruby can be shared across ruby implementations and pure-ruby
packages should be packaged (and are required to by guidelines) such
that you can for example `dnf install rubygem-webrick` and the just run
that with JRuby via rubypick or other means.
As I mention on other places in this email, guidelines and our packaging
is done with alternative Ruby runtimes in mind (such as JRuby), but
there wasn't much of a request and time for alternative runtimes, so it
has been just CRuby since the JRuby in Fedora was retired.
>
> We also publish the entire dist to Maven:
> https://central.sonatype.com/artifact/org.jruby/jruby-dist. The main
> jar file we ship is largely equivalent to the `jruby-core` Maven
> artifact, with all third-party JVM libraries bundled into the same file.
>
> I'm not sure how finely the JRuby dist would need to be sliced up to
> become an acceptable Fedora package. Looking at standard Ruby packages
> from https://packages.fedoraproject.org/pkgs/ruby/ it doesn't appear
> that each individual standard library is split off into its own
> package, and there's some aggregate packages for "bundled"
> (preinstalled) and "default" (in stdlib but upgradable) gems. JRuby
> has the same basic split and roughly the same layout of how we ship
> the standard library.
I can provide some context here. We had tried to keep each library in
its own separate, but later (around ~ Ruby 3.0 timeframe I think?)
defaulted to providing them in the ruby-bundled-gems and
ruby-default-gems collections and the rest of the gems that were split
before this are just standalone (for example: rubygem-rexml).
>
> Perhaps someone who maintains the existing Ruby packages could help me
> figure out what needs to change to support the same packages for JRuby?
I am not sure here at the full scope that JRuby would require adjusting.
There are things, such as rubygems-devel containing various macros for
help with rubygems packaging that are more or less standardized.
I am not sure of interoperability of gems with CRuby extensions with
JRuby, how would rubygems behave in that case, whether it'd recognize
that there is no Java compat and would just say it doesn't exist or what
would happen. Though this is problem (or maybe isn't?) for packaged gem
libraries, user-installed libraries in $HOME should not get intermixed
between engines.
I'd mention a project "rubypick" that is here from when JRuby was
packaged in Fedora years ago and allows switching which Ruby engine is
running with ease https://src.fedoraproject.org/rpms/rubypick .
rubygems-* packages are packaged (and Ruby Fedora packaging guidelines
[2] ).
There is also custom operating_system.rb we inject into rubygems during
build that generates our paths for gems that are consistent with Fedora
guidelines. [3]
I also recommend the %configure section of the ruby.spec [4] which could
offer further inspiration and prevent gotcha's, such as shared rubygems
path `/usr/share/rubygems`, and shared system(dnf)-installed gem path
`/usr/share/gems`.
Regards,
Jarek
[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/
[3]
https://src.fedoraproject.org/rpms/ruby/blob/62e62cae3c177ad600f659dda5765f…
[4]
https://src.fedoraproject.org/rpms/ruby/blob/62e62cae3c177ad600f659dda5765f…
Welcome! I am one of the Ruby Fedora packagers, I am happy to see
interest for extending Ruby engines offerings in Fedora.
On 5/12/26 7:37 PM, Charles Oliver Nutter wrote:
> Disclaimer: I am a JRuby developer and currently leading the project.
>
> JRuby has been seeing a big burst of development recently and we have
> been getting requests from users for there to be official packages on
> their Linux of choice. Today that Linux is Fedora (or downstream
> derivatives like Bazzite).
>
> We are interested in helping to revive the JRuby package for Fedora.
> JRuby today runs on JDK 21+ and installation requires little more than
> unpacking a tarball (plus appropriate path tweaks etc). There's not
> much to do to get it into a package, but I am unfamiliar with the
> testing done for the standard Ruby package and how much of that
> applies to JRuby.
There are 2 sets of tests, 1) Upstream that run during build, those
discover issues on their own, and 2) our Fedora tests. And I'd say a
significant amount of CRuby configurations apply to JRuby as well, we
have shared rubygems, shared gems, ... between Ruby engines. But a lot
of it ran on just CRuby for some time, so we might discover some edge
cases along the way.
For Fedora tests, there is https://src.fedoraproject.org/tests/ruby ,
though I'd like to see many more tests that could test the integration
into the Fedora ecosystem, but there have not been much time to give it.
We could share some portion of tests in that repo, TMT is quite flexible.
So, there isn't "much" testing outside of reviews when package is
introduced so that it has all the required things necessitated by
general and ruby-specific Fedora Guidelines.
One way to test changes with CRuby's integration is build the package,
install it in mock or on a test machine and try to build in that
environment some ruby package and run it, which excersizes paths,
loading and other "basics" that have to be right for things to work
together.
There is some support for multiple Ruby runtimes in Fedora, even going
as far as being able to interchangeably run with pure-ruby Fedora
packaged gems via rubypick (for more see the deeper in-thread response).
>
> If this is not the correct place to discuss it, please let me know. I
> ended up here by following instructions at
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Packag…
This is correct place and I'd mention also that we have ruby-sig
https://fedoraproject.org/wiki/SIGs/Ruby (mailing list cc'd) where we
discuss Rub(y|ies) in Fedora.
Thanks,
Jarek
>
> *Charles Oliver Nutter*
> /Architect and Technologist/
> Headius Enterprises
> https://www.headius.com
> headius(a)headius.com
>