https://bugzilla.redhat.com/show_bug.cgi?id=1933464 --- Comment #12 from Vít Ondruch <vondruch@xxxxxxxxxx> --- (In reply to Phil Dibowitz from comment #11) > * The ruby packaging guidelines are clear here, and they afaict disagree > with you: > > ``` > Packages that contain Ruby Gems MUST be called rubygem-%{gem_name}. > ``` > > The binary package that provides an application I don't think makes sense as > rubygem- but the requirements are clear that the base package must be > rubygem- This part of guidelines applies for applications: ~~~ Application packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the general Naming Guidelines instead. ~~~ I agree that the guidelines are ambiguous at this point, but I am afraid there is no clear cut. The guidelines certainly were not meant in a way to have `rubygem-foo` SRPM and while having only `foo` RPM. The good question to ask when deciding is the question if there is any other use for the package as a library. Looking on sugarjar reverse dependencies [1], nothing depends on it, therefore it is certainly good candidate for application. And if you like down bellow on the application example, while quite old one, you would see that the deltacloud-core is distributed as a gem, but later installed into regular `%{_datadir}` structure. The confusion comes from duality of RubyGems: 1) It is good distribution method for Ruby code while 2) It is also Ruby load path manager But at this point, I am not sure I have not made the water just muddier ů > * I can poke at reordering the globals in the next build, I assume that's > what you mean No, I meant that for example the `Source` directives are at the end of preamble. While it is certainly possible, it is uncommon. This is just minor nit of course. > * The specs are unit tests not functional tests and do not work in the > installdir, they only work in the source, which is why I did it that way. This way it works: ~~~ %if %{with tests} %check pushd .%{gem_instdir} cp -a %{_builddir}/spec . rspec spec popd %endif ~~~ I think you could struggle with the symbolic link. I prefer to use them whenever possible, but the `cp` have to be used here instead. The issue is that the link does not play nice with `require_relative` used in the test suite. > I did originally use gem2rpm, but it went through a lot of revisions since > then... I like to keep my spec files as close to the original gem2rpm output as possible, because I always use gem2rpm even for updates. This serves two purposes: 1) If there are some changes in RubyGems packaging best practices, I'll notice them and can incorporate them into the .spec file 2) It helps to notice changes in upstream, such as added/removed files, different build dependencies. I am not saying this is the only way to do the packaging, but it works for me ;) > Feedback appreciated! [1] https://rubygems.org/gems/sugarjar/reverse_dependencies -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
