<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dne 29.2.2012 17:53, Toshio Kuratomi napsal(a):
<blockquote cite="mid:20120229164852.GA28286@unaka.lan" type="cite">
<pre wrap="">On Wed, Feb 29, 2012 at 06:43:14AM -0500, Mo Morsi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">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?)
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">I'll try but you may need to pass my message through the ruby-sig
moderation queue.
-Toshio</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
packaging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:packaging@lists.fedoraproject.org">packaging@lists.fedoraproject.org</a>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/packaging">https://admin.fedoraproject.org/mailman/listinfo/packaging</a></pre>
</blockquote>
<br>
Hi Toshio,<br>
<br>
Today, in attempt to find some compromise solution, we tried to
"fix" RubyGems in a way, that would allow the following workflow:<br>
<br>
%prep<br>
%setup -q -c -T<br>
mkdir -p .%{gem_dir}<br>
gem install --local --install-dir .%{gem_dir} \<br>
--force \<br>
--skip-build \<br>
%{SOURCE0}<br>
<br>
%build<br>
pushd .%{gem_dir}/ext<br>
./configure && make && make install<br>
popd<br>
<br>
%install<br>
mkdir -p %{buildroot}%{gem_dir}<br>
cp -a .%{gem_dir}/* \<br>
%{buildroot}%{gem_dir}/<br>
<br>
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.<br>
<br>
First of all, the '"./configure && make && make
install" (or some equivalent)' is tricky, since there are currently
3 supported build methods by RubyGems<br>
<br>
1) Traditional ./configure && make && make install"<br>
2) The most widely used extconf.rb and make combo<br>
3) Rake builder<br>
<br>
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.<br>
<br>
In conclusion, this is dead end. The "--skip-build" option doesn't
look promising ATM unless the RubyGems would undergo some
significant changes.<br>
<br>
<br>
Vit<br>
<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L229">https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L229</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://github.com/rubygems/rubygems/tree/master/lib/rubygems/ext">https://github.com/rubygems/rubygems/tree/master/lib/rubygems/ext</a><br>
</body>
</html>