packaging-committee

#1512 Building rubygem-cucumber-messages as a subpackage of cucumber-messages?
Closed: accepted by james. Opened by music.

Closed: accepted
Reopen Issue

In https://src.fedoraproject.org/rpms/cucumber-messages/pull-request/2, @vondruch has proposed building rubygem-cucumber-messages as a subpackage of cucumber-message in lieu of maintaining it as a separate source package.

Independent of packaging policy, my personal view of this change is generally favorable:

  • Vít is an experienced packager, and is particularly knowledgeable and active in Ruby packaging. I expect Vít has thought this through and understands the implications.
  • It’s easier to keep one package up to date than two.
  • As Vít noted, packaging from the full source tree rather than the gem archive makes it possible to re-create generated source code. (It also covers the requirement that the original sources for generated code must be included in the source package.)

However, I have one big concern: this plan seems to run counter to the Ruby packaging guidelines, specifically, for RubyGems, “The Source of the package MUST be the full URL to the released Gem archive.”

(In Rust packaging, we have a similar prescription for crate libraries, and we adhere to it very strictly, for good technical reasons.)

The purpose of this issue is to ask for an opinion on whether treating cucumber-messages (and possibly other related packages, such as gherkin) as an exception to this rule is wise and/or justified. If the answer is affirmative, then a follow-up question will be, what are the general criteria that would justify such an exception? And can they be written into the guidelines?

I will send a link to this issue to the ruby-sig mailing list for visibility and to solicit input.

https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/thread/PSKJUY6T7CI6GJQKQMMALX624AVK5T4M/

One think I'd like to note that if this approach does not raise any concerns, I'd like to follow with similar approach with other packages from Cucumber family.

I wonder what the spirit of the guideline is. E.g. in Python we say "The command pip install PROJECTNAME MUST install the same package (possibly in a different version), install nothing, or fail with a reasonable error message."

In my view, as long as the resulting package provides the same code as if it were packaged from the Gem source, it's reasonable enough.

I wonder what the spirit of the guideline is

Interesting question.

The main motivation for having the guidelines as they are is that the .gem from RubyGems might have different content then when it is built from source. The reason is that the .gemspec might contain various wildcards, therefore include different files in resulting .gem. So the assumption is that upstream has consistent release process and the .gem contains what is should. While the .gem package is rebuilt during the RPM build, also the .gemspec used for rebuild does not contain wildcards anymore, because the build process replaces them with file list (if I lost you by the explanation, that is another reason for the guidelines 😉).

Second motivation is consistency and simplification. The skeleton of all rubygem- packages looks similar, which is pretty convenient. If there were various sources, it would be harder to maintain the packages.

However, I don't think that the guidelines ever considered case that .gem would be part of bigger project, which even provides support for more languages and the relation is so tight.
Edited by vondruch

Does FPC plan to express an opinion on this? I would like to be able to accept (or, if necessary, reject) this PR rather than letting it linger in limbo indefinitely.

I would treat silence as an agreement with this proposal 😇

The first FPC meeting of the new year will happen übermorgen, I suspect that we will discuss it there. (I also added the "meeting" tag to give it better chances.)

Metadata Update from @decathorpe:
- Issue tagged with: meeting

In case I won't attend the meeting, my stance is that I would allow this for this particular case, and if we want to enable it more globally, it probably needs some general criteria.

In case I won't attend the meeting, my stance is that I would allow this for this particular case, and if we want to enable it more globally, it probably needs some general criteria.

Thanks. If the committee agrees with this, I’d like to interpret this particular case as encompassing all similar packages associated with the cucumber project, such as https://src.fedoraproject.org/rpms/gherkin.

This is still unresolved. I’ll see if I can remember to show up at the next FPC meeting and raise it during open floor.

The next meeting is planned for April 16, 11:00 UTC-4 (America/New_York). I'm not sure why tagging this with "meeting" hasn't caused us to discuss it yet.

Python packages will have similar problems, so while an opinion on this package would be helpful, general guidelines are useful for the whole project.

Python packages will have similar problems, so while an opinion on this package would be helpful, general guidelines are useful for the whole project.

Hmm, I am having a hard time seeing the connection to Python. There has never been a requirement to use only PyPI sdists for packaging Python libraries, and the current guidelines even caution against doing so in cases where tests or other important files are not present in the sdists.

There have been attempts to force PyPI for Python stuff. They have so far failed because PyPI isn't a consistently reliable source for usable sources.

Sorry this issue got dropped.

In case I won't attend the meeting, my stance is that I would allow this for this particular case, and if we want to enable it more globally, it probably needs some general criteria.

Thanks. If the committee agrees with this, I’d like to interpret this particular case as encompassing all similar packages associated with the cucumber project, such as https://src.fedoraproject.org/rpms/gherkin.

We talked about it today and are fine approving this, so you can move forward.

For a more general solution if you open a PR to relax the guidelines to what you want, we'll likely approve that too (if it's just s/MUST/SHOULD/ or something more involved).

Metadata Update from @james:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

Should there come some PR, please keep me in loop 🙏

For a more general solution if you open a PR to relax the guidelines to what you want, we'll likely approve that too (if it's just s/MUST/SHOULD/ or something more involved).

Please see https://pagure.io/packaging-committee/pull-request/1532. (@vondruch, your review would be especially appreciated.)
Metadata
None

meeting

None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.