On Mon, Mar 18, 2013 at 11:13 AM, Vít Ondruch <vondruch@redhat.com> wrote:

You can use the same approach we used previously for other macros, e.g.

%{?!gem_install: %global %gem_install(d:n:) \
mkdir -p %{-d*}%{!?-d:.%{gem_dir}} \
\
CONFIGURE_ARGS="--with-cflags='%{optflags}' $CONFIGURE_ARGS" \\\
gem install \\\
        -V \\\
        --local \\\
        --install-dir %{-d*}%{!?-d:.%{gem_dir}} \\\
        --bindir .%{_bindir} \\\
        --force \\\
        --document=ri,rdoc \\\
        %{-n*}%{!?-n:%{gem_name}-%{version}.gem} \
%{nil}
}

Or some simplified version. Please note that I did not tested this macro, so I am pretty sure it does not work out of the box ;) Of course if you can express your voice in this ticket [3], that wold be best :)

That is ugly I must say. This might be better:

%if 0%{?fedora} > 18
%gem_install
%else
mkdir -p .%{gem_dir}
gem install --local --install-dir .%{gem_dir} \
            --force --rdoc %{gem_name}-%{version}.gem
%endif


And the best is to not share the .spec file.

Honest question. Why is not sharing the .spec file the best option? I find that maintaining multiple versions of my spec files is a significant increase in workload and worries me that its more prone to errors of the typo variety.

Along those lines. If the same macros were available in epel is there any reason the same spec files wouldn't work everywhere? What I'm getting at is would be any value in creating a package that provided the same macros for older releases which could be included as a BuildRequires for older packages.  I'm just a bit worried about adding the header to my epel packages isn't really maintainable since I'd need to update every package using it if I discovered a bug or another reason it needed to be changed.

Russell