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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging