undeprecating rubygem-{bunny,moneta,ohai}

[Julian C. Dunn]

Hi,

Mo Morsi pointed me over here from -devel. I'm working on packaging Opscode Chef for Fedora and EPEL 6 (EPEL 5 is too old to do this sanely)

The first step for me is to un-deprecate the above packages. I have specfiles ready to go, except I have one question about "Requires: ruby(abi) = XXX".

What should the correct value be, given that I want to support EPEL 6 (has Ruby 1.8) and current Fedoras (have Ruby 1.9)? Is it acceptable to wrap this in a conditional, example:

%if %{?el6}
Requires: ruby(abi) = 1.8
%else
Requires: ruby(abi) = 1.9.1
%endif

or not?

- Julian

[Vít Ondruch]

Dne 1.11.2012 21:51, Julian C. Dunn napsal(a):
> Hi,
>
> Mo Morsi pointed me over here from -devel. I'm working on packaging Opscode Chef for Fedora and EPEL 6 (EPEL 5 is too old to do this sanely)
>
> The first step for me is to un-deprecate the above packages. I have specfiles ready to go, except I have one question about "Requires: ruby(abi) = XXX".
>
> What should the correct value be, given that I want to support EPEL 6 (has Ruby 1.8) and current Fedoras (have Ruby 1.9)? Is it acceptable to wrap this in a conditional, example:
>
> %if %{?el6}
> Requires: ruby(abi) = 1.8
> %else
> Requires: ruby(abi) = 1.9.1
> %endif

If you don't plan to support this package in F16, then this is just 
fine. However, please note that there is not available rubygems-devel 
package in EPEL6, so you will need to define also following variables 
for EPEL to keep the spec compatible between EPEL and Fedora

%global gem_dir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
%global gem_instdir %{gem_dir}/gems/%{gem_name}-%{version}
%global gem_docdir %{gem_dir}/doc/%{gem_name}-%{version}
%global gem_cache %{gem_dir}/cache/%{gem_name}-%{version}.gem
%global gem_spec %{gem_dir}/specifications/%{gem_name}-%{version}.gemspec

Vit
> or not?
> Julian
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Julian C. Dunn]

Thanks Vit -- I had to make a couple other changes so that the EPEL6 mock build would finish successfully.

Before I invest the effort in the other packages, I'd like to get sign-off that what I've done for rubygem-bunny is ok. Can someone review  https://bugzilla.redhat.com/show_bug.cgi?id=821285 and let me know?

- Julian

On Nov 2, 2012, at 3:18 AM, Vít Ondruch  wrote:
> Dne 1.11.2012 21:51, Julian C. Dunn napsal(a):
> > Hi,
> >
> > Mo Morsi pointed me over here from -devel. I'm working on packaging Opscode Chef for Fedora and EPEL 6 (EPEL 5 is too old to do this sanely)
> >
> > The first step for me is to un-deprecate the above packages. I have specfiles ready to go, except I have one question about "Requires: ruby(abi) = XXX".
> >
> > What should the correct value be, given that I want to support EPEL 6 (has Ruby 1.8) and current Fedoras (have Ruby 1.9)? Is it acceptable to wrap this in a conditional, example:
> >
> > %if %{?el6}
> > Requires: ruby(abi) = 1.8
> > %else
> > Requires: ruby(abi) = 1.9.1
> > %endif
>
> If you don't plan to support this package in F16, then this is just fine. However, please note that there is not available rubygems-devel package in EPEL6, so you will need to define also following variables for EPEL to keep the spec compatible between EPEL and Fedora
>
> %global gem_dir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
> %global gem_instdir %{gem_dir}/gems/%{gem_name}-%{version}
> %global gem_docdir %{gem_dir}/doc/%{gem_name}-%{version}
> %global gem_cache %{gem_dir}/cache/%{gem_name}-%{version}.gem
> %global gem_spec %{gem_dir}/specifications/%{gem_name}-%{version}.gemspec
>
> Vit
> > or not?
> > Julian
> >
> > ruby-sig mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Darryl L. Pierce]

On Thu, Nov 01, 2012 at 04:51:30PM -0400, Julian C. Dunn wrote:
<snip>
> What should the correct value be, given that I want to support EPEL 6 (has Ruby 1.8) and current Fedoras (have Ruby 1.9)? Is it acceptable to wrap this in a conditional, example:
>
> %if %{?el6}
> Requires: ruby(abi) = 1.8
> %else
> Requires: ruby(abi) = 1.9.1
> %endif
>
> or not?

A note on specfile style: since we have a separate branch for each
target version, you don't need to use the above conditional. Instead, on
your el6 just use:

Requires: ruby(abi) = 1.8

and on F17+ us

Requires: ruby(abi) = 1.9.1

[Ken Dreyer]

On Fri, Nov 2, 2012 at 8:24 AM, Darryl L. Pierce  wrote:
> A note on specfile style: since we have a separate branch for each
> target version, you don't need to use the above conditional. Instead, on
> your el6 just use:
>
> Requires: ruby(abi) = 1.8
>
> and on F17+ us
>
> Requires: ruby(abi) = 1.9.1

Technically that's true, but it doesn't allow you to have a unified
spec file for all branches of Fedora and EPEL. It's quite nice to be
able to do fast-forward merges in Git, instead of having visible merge
commits, or instead of manually cherry-pick changes.

It's up to the maintainer to decide of course. I've just found it's
much easier to follow development on a package when the spec is
unified like this. EPEL in particular hangs around for a very long
time!

- Ken

[Darryl L. Pierce]

On Fri, Nov 02, 2012 at 08:42:13AM -0600, Ken Dreyer wrote:
> On Fri, Nov 2, 2012 at 8:24 AM, Darryl L. Pierce  wrote:
> > A note on specfile style: since we have a separate branch for each
> > target version, you don't need to use the above conditional. Instead, on
> > your el6 just use:
> >
> > Requires: ruby(abi) = 1.8
> >
> > and on F17+ us
> >
> > Requires: ruby(abi) = 1.9.1
>
> Technically that's true, but it doesn't allow you to have a unified
> spec file for all branches of Fedora and EPEL. It's quite nice to be
> able to do fast-forward merges in Git, instead of having visible merge
> commits, or instead of manually cherry-pick changes.
>
> It's up to the maintainer to decide of course. I've just found it's
> much easier to follow development on a package when the spec is
> unified like this. EPEL in particular hangs around for a very long
> time!

Honestly, I've not done that before. I inherited one package that had a
ton of conditionals that I found hard to follow. I ended up pulling them
out, but now wonder if maybe it couldn't have been simplified instead.