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&oldi...
> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging