[Fedora-packaging] New packaging guidelines for Ruby

Vít Ondruch vondruch at redhat.com
Thu Mar 1 09:05:58 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.

Well it is hard to bring you some example, because there are non. There 
are no experiences with the #3 except with rubygem-idn, and in this case 
the simple approach described in guidelines fails. Try to remove the 
following lines from the spec:

# Avoid "cert_chain must not be nil" error.
sed -i -e "10d" %{gem_name}.gemspec

and you'll see what I am talking about. Please do not ignore these 
custom lines I had to come up with to let the #3 work.

>
> #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.

Yes, it will not be simple to apply changes, therefore we are moving 
from approach #1 which was valid up until now and proposing the approach 
#2, which works well for all packages except rubygem-idn

>
> #2 does not fix the problem with rpmbuild --short-circuit.

To be honest, I do not understand what is the point with the 
--short-circuit. According to documentation "--short-circuit skip 
straight to specified stage (only for c,i)". I do not know how are you 
using it, but it implies that you have to do "rpmbuild -bp" to be able 
to do "rpmbuild -bc --short-circuit". In that case, what does not work 
for you? What do you want to see in this step if it is empty?

>
> #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.

You should understand that RubyGems is packaging system and if I am 
packaging the gem for Fedora, I am user of the packaging system from 
point of view of RubyGems and I am package maintainer form point of RPM. 
No need to argue about "packager's job". I just wanted to find something 
what would give you better feeling what is it about and I gave better, 
more detailed, example along the lines somewhere in this thread to Rex.

>
> 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.

I am not familiar with python, but you cannot compare "make install" 
with "gem install". It is something really different. Moreover, "make 
install" doesn't necessarily mean that the "configure && make" will be 
run before.

>
> #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.

Yes, you see just script which do conversion, but you do not count the 
exceptions. Once more, I used #3 for rubygem-idn, the only gem which 
required it and in this one case it immediately failed. So for me it is 
a *100% failure* of your conversion script.

 From last versions of packaging guidelines we moved from #1 to #2 which 
solves practical problems. Move from #2 to #3 solves some artificial 
problems.

Yes, I agree with you that if differs a bit from other packages. Yes, I 
agree with you that it could be better. Yes, I proposed that I will work 
with upstream to allow better way of patching C extensions, without need 
to move to #3. Neither of this seems to satisfy you.


Please note that this [1] was the last proposal coming from me and 
Ruby-SIG. I am not against formal changes of the guidelines, as was done 
by Toshio, if FPC believes they will be better aligned with other 
guidelines. I never said nothing against. I totally support that effort. 
When I was asked to come up with the way how to patch the C extensions 
and I did that. However I am strongly against mandatory #3.



Vit

[1] 
https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&oldid=270494

>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120301/58a65a69/attachment-0001.html>

More information about the ruby-sig mailing list