Sorry, I forgot trac uses wikiformatting:

{{{
%if 0%{?fedora} && 0%{?fedora} < 17
Requires: %{?scl_prefix}ruby(abi) = 1.8
%else
%if 0%{?fedora} && 0%{?fedora} > 18
Requires: %{?scl_prefix}ruby(release)
%else
Requires: %{?scl_prefix}ruby(abi) = 1.8
%endif
%endif
}}}

is what the spec normally looks like for a gem or lib.

Since I've become more interested in Ruby packaging, I've often thought that the current situation was a head-scratcher.

Check out the [https://lists.fedoraproject.org/pipermail/ruby-sig/2012-April/000968.html discussion on the ruby-sig list over a year ago]. Since that thread, the Ruby SIG has gone in yet another different direction with a completely unversioned ruby(release).

The way that Perl does this (just use whatever was in the buildroot) makes more sense to me. I hope RHEL 7 picks something sane or we're going to have some ugly conditionals for a very long time.

Yep, agreed. Basically I'd like for there to be a way that everyone can use to ensure the proper name and version can be used to remove duplication between specs.

What Ruby version is required for runtime is external information. You typically cannot get this information automaticaly from code, unless you thoroughly test it. The only person who can tell if the Ruby code is compatible with certain version of Ruby interpreter is be upstream.

So what is the point of macro such as %{ruby_abi_release}, which tells only against which version of Ruby the library was build, but don't say anything about actual compatibility of code with specific Ruby runtime. That is the reason, why there is no such macro and will never be.

Just FYI, RHEL7 stays with ruby(release) as in recent Fedoras. ruby(release) might be versioned, but this is discouraged.

Also (slight OT), on different lists, I was advocating for different .spec per version of Fedora [1] and I am not alone in this effort [2]. In such case, you would not suffer the pain caused by conditionals. Since I maintain more then 100 ruby packages, I know what I am talking about, believe me.

[1] https://lists.fedoraproject.org/pipermail/packaging/2013-March/008936.html [[BR]]
[2] https://lists.fedoraproject.org/pipermail/devel/2013-July/186689.html

Also note there is lengthy discussion on packaging list which was behind the change from ruby(abi) to ruby(release) virtual provide.

[1] https://lists.fedoraproject.org/pipermail/packaging/2012-December/008798.html

Hi Vít, I remember that discussion on fedora-devel, and I didn't speak up at the time because that thread was getting wildly out of hand. I'll do so now. I politely disagree that we can dismiss this problem out of hand by saying "just don't share spec files across distros". The number one reason that I contribute to Fedora is because of EPEL. If we expressly make it harder to share specs between the distros, we're discouraging contributors, and we're making it all the harder to get good Ruby ecosystem support on RHEL.

As you said, you maintain more than 100 rubygem packages, and please know that I'm really thankful for the work you do. I myself have been working for over a year on several dozen rubygems in a private repository. The reason that I don't maintain more gems is due in large part to the fact that the Ruby guidelines drastically change every other Fedora release. When my ultimate focus is making things work on RHEL, it's just too hard to keep up, and I'm discouraged from contributing more to Fedora. That's why I welcome a proposal like Sam's.

Sure, some of the problem is that Ruby upstream eschews backwards compatibility (eg 1.8.7 -> 1.9.3 were way too different.) I just think that Fedora itself shares some of the responsibility for not making this easier too.

Regarding your point about the upstream being the sole source of truth for runtime compatibility, I would politely disagree with that as well. For example, take a look at the average upstream gemspec, and you'll often find that the exact gem version number restrictions are not accurate. I've had to file more than one bug to get upstream authors to loosen their dependency version numbers. One author was even a Red Hat developer :) The gems worked fine with Fedora's particular dependencies, and it was just that the upstream gem authors hadn't considered that particular combination of dependencies. I see this as simply part of the routine of doing packaging work in a Linux distro: we are always testing things, and we often find things that upstream misses.

When I read your emails to the lists, I believe that you and I ultimate share the same goals; more gems, easier maintenance, smoother evolution for Ruby in Fedora. I believe that a macro like what Sam's proposed (or even something like what Perl does) would benefit Ruby packaging overall.

Ken, I am not going to comment on each point you made, because it would derailed the discussion. Nevertheless, I believe we agree that we both like to make packaging easier.

The problem with the proposed macro is that we already did the requested change. We introduced ruby(release) macro which replaces the changing ruby(abi) macro. We did that already for F19 and ruby(release) is going to stay with us for foreseeable future.

The proposed macro can't change anything for EPEL unfortunately, since it would take ages to propagate into RHEL, you know it the best I believe.

We are tabling this until RHEL adds support for a macro like described in the original ticket. Without that, even we added it to Fedora, you'd have to conditionalize the macro to cover EPEL, which is just silly given that you're trying to remove one set of %if/%else. :)

It was noted in the meeting that the conditional in the topic simplifies down to:

{{{
%if 0%{?fedora} && 0%{?fedora} < 17
Requires: %{?scl_prefix}ruby(abi) = 1.8
%else
Requires: %{?scl_prefix}ruby(release)
%endif
}}}

Also noteworthy is that Fedora < 17 is no longer supported, so it's really the EPEL case that first conditional covers.

This is very old. Is there still anything for the committee to consider here?

No response; closing. Please feel free to reopen if you have more information to add.