[Fedora-packaging] New packaging guidelines for Ruby

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120229/63f1caaa/attachment.sig>