#242 Proposed Ruby guidelines update
Closed: Fixed None Opened 11 years ago by bkabrda.

Hi,
I'd like to propose a Ruby guidelines change. The new draft is at [1] and to make it easier, the diff between current guidelines and the draft is placed at [2]. The incorporated changes are:

  • switch ruby(abi) for ruby(release) as discussed on packaging list [3]

  • changes to get ready for full JRuby integration (we're going to have new JRuby, but the packaging is turning out to be more complex, so we'd like to take more time to figure it out properly - F20 is the estimate) - these changes include some wording, change of %gem_extdir macro to %gem_extdir_mri and few connected things

  • a fix for expanded %gem_dir macro (not /usr/share/rubygems, but /usr/share/gems)

Thanks.

[1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby

[2] http://www.diffchecker.com/6n3o63r0

[3] http://lists.fedoraproject.org/pipermail/packaging/2012-December/008798.html


Please note that the proposed change from ruby(abi) to ruby(release) applies just to F19+. The %{gem_extdir_mri} {c,sh}ould be backported.

Hey, we discussed this in the FPC Meeting today. The general idea of sharing modules since the majority of code will run on either interpreter seems to be fine with most people so it's just details of how to implement that that we'll need to figure out.

I've added the questions that people came up with at the meeting here:

https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Questions

For some of those questions (like: add rubypick to the guidelines), I think that you could just make the change and mark it done in the Q&A. For issues that need discussion, it's probably best to talk them through on the packaging@lists.fp.o mailing list. (Could also continue the threads from the FESCo discussion on devel@ but things that need FPC attention do tend to get lost among the other messages there.)

(@bkabrda: I mentioned this in the FESCo meeting to mmaslano too -- if you want to talk to me on IRC about some portion of this, let me know a time in advance and I'll try to be awake to meet with you.)

Meeting log is here: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-23/fedora-meeting-1.2013-01-23-17.06.log.html

Ruby portion starts at:
17:55:38 <abadger1999> #topic Ruby Guidelines update: https://fedorahosted.org/fpc/ticket/242

We have done the mentioned modifications in guidelines, see the diff [1]. Toshio, thanks for your offer of IRC meeting. If we don't agree on the new guidelines and features by the end of the week, let's meet sometime next week.

Thanks.

[1] https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=320523&oldid=320429

Ruby Guideline update passed with changes: (+1: 6, 0:0, -1: 0)

@spot: Guidelines updated and ready to be announced.

@bkabrda:

There were some changes made during today's meeting: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=321621&oldid=320523

The shebang line/rubypick changes were for clarification and should be pretty noncontroversial. As a note, we decided that given how rubypick is being used, we don't think the question of command line vs environment variable belongs to us. We've let mitr/fesco know that it's for them to decide and we'll update the Guidelines if they decide that the command line form should not be used.

The unittest portion we talked about in the meeting and decided that running tests actually is mandated (although not required). Here's the general guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Test_Suites

"If the source code of the package provides a test suite, it should be executed in the %check section, whenever it is practical to do so."

There's also a section in the current ruby guidelines that reiterates this: https://fedoraproject.org/wiki/Packaging:Ruby#Running_test_suites

"If there is test suite available for the package (even separately, for example not included in the gem but available in the upstream repository), it should be run in %check. The test suite is the only automated tool which can assure basic functionality of the package. Running it is especially helpful when mass rebuilds are required. You may skip test suite execution when not all build dependencies are met but this must be documented in the specfile. The missing build dependencies to enable the test suite should be packaged for Fedora as soon as possible and the test suite re-enabled."

We tried to craft the wording for running test suites under alternate interpreters to match the main Ruby#Running test suites section so that the same exceptions were granted.

I know that this doesn't address the overhead of pulling in jruby in order to do builds. In the build system it seems like the benefit of this outweighs the cost. However, if you think that this is too painful for package maintainers doing local builds, perhaps we can think of something to let them opt out of it on their local builds. For instance, we could have a switch to turn off doing the alternate interpreter tests:

{{{
%global with_alternate_ruby 0%{!?_without_alternate_ruby:1}

[...]

%if 0%{?with_alternate_ruby}
BuildRequires: jruby
%endif

[...]

%check

%if 0%{?with_alternate_ruby}
testrb jruby -Ilib test
%endif
}}}

In the buildsystem, this would always run the tests. But package maintainers that were iterating their packages at home could use {{{rpmbuild -ba --without alternate_ruby}}} to build without it. This is something I just came up with; if you like it, I'll need to run it by the rest of FPC to be approved.

Thank you. As for the changes you've made to the guidelines, we're ok with them. (A note: currently old Ruby guidelines for F16 are stored and referred from current Ruby guidelines. I think it'd be beneficial to also keep the F17 guidelines and reference them because of EPEL.)

We've been discussing the JRuby overhead with Vit and we think we should try doing it how it is currently mentioned in the new guidelines; if that turns out to be too non-practical, we will work with you to solve it for next Fedora release by introducing/recommending usage of some macros.

Thanks.

Replying to [comment:5 bkabrda]:

Thank you. As for the changes you've made to the guidelines, we're ok with them. (A note: currently old Ruby guidelines for F16 are stored and referred from current Ruby guidelines. I think it'd be beneficial to also keep the F17 guidelines and reference them because of EPEL.)

Better to say that the f16 guidelines (currently referred as old) should be kept, since they are still valid for EPEL and another copy of the f17-f18 guidelines should be kept around (may be link into history should be enough), since they still applies to older Fedoras

Thanks for the note! I've linked into the history for older Fedoras. A note for future update: When the guideline changes are mostly compatible, it's nicer to have inline notes about what changes are needed for different versions of Fedora rather than a whole separate document. That makes it easier for a packager wanting to share spec files between multiple Fedora releases to see what they need to do and easier for a package reviewer to understand the tricks a packager may be using to remain compatible with several different Fedora releases.

Login to comment on this ticket.

Metadata