[Fedora-packaging] New packaging guidelines for Ruby

Fri Mar 9 13:57:30 UTC 2012

Dne 29.2.2012 17:53, Toshio Kuratomi napsal(a):
> On Wed, Feb 29, 2012 at 06:43:14AM -0500, Mo Morsi wrote:
>>> Ok, I'll give you 3 examples:
>>>
>>> = Old guidelines, used from the time RubyGems were packaged for Fedora =
>>>
>>> %prep
>>>
>>> %build
>>>
>>> %install
>>> mkdir -p %{buildroot}%{gem_dir}
>>> gem install --local --install-dir %{buildroot}%{gem_dir} \
>>>              --force %{SOURCE0}
>>>
>>>
>>>
>>>
>>> = What we are proposing =
>>>
>>> %prep
>>> %setup -q -c -T
>>> mkdir -p .%{gem_dir}
>>> gem install --local --install-dir .%{gem_dir} \
>>>              --force %{SOURCE0}
>>>
>>> %build
>>>
>>> %install
>>> mkdir -p %{buildroot}%{gem_dir}
>>> cp -a .%{gem_dir}/* \
>>>          %{buildroot}%{gem_dir}/
>>>
>>>
>>>
>>>
>>> = What FPC is proposing =
>>>
>>> %prep
>>> %setup -q -c -T
>>> pushd ..
>>> gem unpack %{SOURCE0}
>>>
>>> pushd %{gem_name}-%{version}
>>> gem spec %{SOURCE0} -l --ruby>  %{gem_name}.gemspec
>>>
>>> gem build %{gem_name}.gemspec
>>> popd
>>> popd
>>>
>>> %build
>>> mkdir -p ./%{gem_dir}
>>> gem install --local --install-dir ./%{gem_dir} \
>>>      --force    ../%{gem_name}-%{version}/%{gem_name}-%{version}.gem
>>>
>>> %install
>>> mkdir -p %{buildroot}%{gem_dir}
>>> cp -a .%{gem_dir}/* \
>>>          %{buildroot}%{gem_dir}/
>>>
>>>
>>> All three versions provide the same output, unless I did some mistake,
>>> since I did not tested it (actually the middle one was taken directly
>>> from rubygem-POpen4.spec). So which version you prefer? Please note
>>> that the "gem install" will always "unpack" the gem with some
>>> additional, for our case unimportant, steps. We do not distribute the
>>> .gem file anywhere.
>> Alternatively we can go with a hybrid of solutions 2 and 3 (your and
>> FPC's proposals) where the 'gem unpack' and 'gem spec' steps are optional.
>>
> As Vit points out, there is no way to implement #2 alone -- it must be
> combined with some form of #3 otherwise you just can't patch C Extensions.
> A hybrid approach, though, could debate when you decide to implement #3
> instead of #2.  (ie: all patching, or only when patching C extensions?)
>
>> The majority of gems do not need an additional modification or patching
>> to be converted into a RPM. Yes these steps bring things more inline w/
>> other packages, but at the expense of unnecessary additional work.
>>
>> If the solution is to suggest gem unpack / gem spec is used while
>> allowing for it to be omitted (still need to determine if gem install
>> should still be run in the %build or %install sections), package
>> maintainers will have a bit more flexibility to run the steps necessary
>> to build their package w/out any additional work, while at the same time
>> still being more compliant and in-line w/ other Fedora practices.
>>
>> Thoughts?
>>
> I've been thinking about this for a week and also waiting for people to
> bring forth packages that would be broken by it to see if there's any actual
> problems with the strategy.  No packages beyond the original one which is
> a bug from upstream has been presented.  Without that sort of example, I'm
> going to vote for #3.
>
> #2 is more complex as people have to keep in mind two sets of instructions.
> When a bug fix is needed, it will not be simple to apply it as you'd have to
> change the whole structure of the spec file in order to apply the patch and
> then revert those changes when the patch is no longer needed.  The
> temptation for the packager in that situation will be to not apply bug fixes
> until after they've made it into an upstream gem release.
>
> #2 does not fix the problem with rpmbuild --short-circuit.
>
> #3 was compared in the ticket with requiring "Fedora users to always rebuild
> each RPM locally, because there might be sometimes broken dependency or
> other error."  This is a wrong comparison.  A packager's job is to deal with
> broken dependencies and other errors, not a users.  #3 requires packagers to
> deal with these issues, not users.
>
> I'm also seeing the argument made for #2 that it's less work because
> a single command exists to do all the steps.  Therefore we should use it.
> This is not a compelling argument because the same can be said of other
> build systems.  For most python code, for instance:
>
> %setup -n %{srcname}-%{version}
> python setup.py install --root %{buildroot}
>
> even "make install" is valid under this argument.
>
> #3 is also (barring someone giving us examples where packages are actually
> broken) only a small one-time cost.  Changing the rubygem spec files that
> are using the old guidelines to use the new guidelines.  As stated earlier,
> the FPC has always known that the Rubygem guidelines needed to be changed
> but was unaware that the time had come when the old guidelines were no
> longer needed (lutter hasn't been on the FPC for years).  Since you're
> proposing changes to the guidelines anyway, you can hardly complain about
> a one-time cost.  In terms of an ongoing cost, until you show that there's
> a non-bug reason that unpacking the source and rebuilding the gem is wrong,
> there's no extra cost in maintaining this that package maintainers shouldn't
> be responsible for anyhow.
>
>> As a side node, if at all possible, please make sure to cc' both lists
>> (packaging and ruby-sig) on replies as this discussion is relevant to
>> both communities. Noticed alot of discussion only on the packaging list
>> meaning the Fedora ruby community is missing out on alot of this.
>>
> I'll try but you may need to pass my message through the ruby-sig
> moderation queue.
>
> -Toshio
>
>
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging

Hi Toshio,

Today, in attempt to find some compromise solution, we tried to "fix" 
RubyGems in a way, that would allow the following workflow:

%prep
%setup -q -c -T
mkdir -p .%{gem_dir}
gem install --local --install-dir .%{gem_dir} \
             --force \
             --skip-build \
             %{SOURCE0}

%build
pushd .%{gem_dir}/ext
./configure && make && make install
popd

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/* \
         %{buildroot}%{gem_dir}/

The main differences are the "--skip-build" flag in %prep section and 
the "./configure && make && make install" (or some equivalent) in %build 
section. In the first moment, it looked promising. Add the 
"--skip-build" flag should be easy as conditionally execution the 
extension's build [1], i.e. almost one line change. Unfortunately, it 
turned out that things are not as easy as they seem on the first look.

First of all, the '"./configure && make && make install" (or some 
equivalent)' is tricky, since there are currently 3 supported build 
methods by RubyGems

1) Traditional ./configure && make && make install"
2) The most widely used extconf.rb and make combo
3) Rake builder

It shouldn't be hard to support also other make alternatives. So these 3 
possibilities complicate the %build section enough. Moreover, if you 
look on the implementation of the builders [2], you'll see that the 
builders are patching the Makefiles on several places, provide 
additional configuration options etc. There is no good place where to 
cut-off the build on some lower layer.

In conclusion, this is dead end. The "--skip-build" option doesn't look 
promising ATM unless the RubyGems would undergo some significant changes.

Vit

[1] 
https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L229
[2] https://github.com/rubygems/rubygems/tree/master/lib/rubygems/ext
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120309/38969de4/attachment.html>