%gem_install macro

[Russell Harrison]

On Mon, Mar 18, 2013 at 11:13 AM, Vít Ondruch <vondruch at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20130321/2fd882c7/attachment.html>