On 5/12/26 7:59 PM, Charles Oliver Nutter wrote:
On Tue, May 12, 2026 at 12:43 PM Fabio Valentini
<[email protected]> 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/62e62cae3c177ad600f659dda5765f431c880c4c/f/operating_system.rb
[4]
https://src.fedoraproject.org/rpms/ruby/blob/62e62cae3c177ad600f659dda5765f431c880c4c/f/ruby.spec#_825
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
