[Mageia-dev] [Cooker] [RFC] Ruby packaging policy

[Per Øyvind Karlsen]

2011/1/7 Remy CLOUARD <shikamaru at mandriva.org>:
> Hello there,
>
> It’s been quite some time since I started working on ruby modules, and
> I’ve been working on the policy too.
\o/
>
> You can find the page here:
> http://wiki.mandriva.com/en/Policies/Ruby
>
> Now, there are some things that still need to be clarified.
>
> The most controversial part is the naming convention.
>
> Many ruby modules are packaged via gem, and fedora introduced a strange
> naming convention, calling their package rubygem-%{gemname}. This
> convention was soon followed by other rpm-based distro such as opensuse
> and momonga, and we also have some of them.
I adopted the rubygem-* naming convention for ruby gems due to the
different way of it being installed opposed to installing it as a
ehr.. non-gem.. (ie. ruby-foo & rubygem-foo would come with the same
ruby module, but installed & packaged differently), to provide a
distinct namespace with less confusion (ie. there seems to be some
conventions on naming ruby modules as ie. 'ruby-foo' for the pure ruby
implementation of 'foo' which might've been written in C etc., always
using the namespace 'rubygem' giving the resulting rubygem-ruby-foo &
rubygem-foo packages) and for the general ease on maintenace by
adopting existing layouts already chosen by other distributions..


>
> I’m not against changing that convention, but this raises also other
> questions.
> 1) Do we also need to change the provides/requires ? ie
No, whatever package filenames chosen, it's really a different topic
than whatever
provides/required that should be generated.
Using rubygem() provides though (yet again) a distinct namespace for these
dependencies automatically generated from the gem metadata, so to ensure these
remaining canonical and without ambiguity, they shouldn't be changed.
Notice that the dependency extractor used is the same one used for
rpm5 upstream,
so by making such changes you'd also end up breaking compatibility
with it as well.
> Requires: ruby(%{gemname})
> instead of
> Requires: rubygem(%{gemname})
> 2) is there a way to make youri watch for rubygem-%{gemname} in case we
> opt for that change ? Or better, can youri watch for %{gemname} on
> rubygems.org ?
provides/requires of ruby gems are already automatically generated to
use rubygem(%{gemname}), so no need to add any explicit provides to
packages and for non-gems where you'd need to add explicit requires on
gems, you should add rubygem(%{gemname}).
>
> Is it ok to add development dependencies as Suggests ? Shall we do a
> -devel subpackage that will pull these dependencies. The advantage of
> doing this is that automated installs will not add these dependencies
> where they aren’t needed, but this will cause spec files to be more
> complicated to maintain (unless we add proper support for this in
> gem2rpm)
Currently it's trivial to add support for generating suggests on these
automatically,
but it's usually not really what's desired with the default behaviour
(with urpmi) of installing
suggests automatically.
Adding support for gem2rpm for creating a meta subpackage would be
trivial, but then you would
have to manually maintain explicit provides/requires for these in the
spec, in contrast to
those automatically generated by rpm during build.
A meta subpackage sounds fairly reasonable (given the current
alternatives rpm provides,
I'm not opposed to implementing something better), but should really be
generated automatically in same fashion from the gem metadata during
build, and not
during initial package creation to be maintained manually afterwards,
but there's no
standard convention for automatically generating sub-packages in place
to use yet.
So if you want support for making use of this metadata in some
sensible and easily maintanable
way, some extra work will be required, as it would fall on rpm's
responsibility to
automatically do so and without extra mess to maintain in packages, I
would advice to
leave it out of packaging policies dictated for packagers to worry
about, rather proposing
it as a feature request for rpm.
>
> About files:
> shall we keep the gem in the cache directory ? I’m not sure this is
> really useful, up till now I added it, but it makes the package a bit
> bigger
Nah, there's no use for it, that's why I implemented gem_helper.rb
(which is what the %gem_build
& %gem_install macros are wrapped around) to drop it by default.
Also notice that gem_helper.rb will also actually recreate the gem
with all the files
that's not of any use dropped, then install this gem.
I *think* the behaviour should be pretty sane and generic enough to
work with most gems
(to my understanding of gem packaging at least;), although the code
itself isn't all that pretty
(some of the very first ruby code I wrote a year ago) and certainly
wouldn't hurt from
being given some care and cleaned up by someone with better ruby
skills and nicer ruby dialect
than mine.. ;)
>
> Shall we do a -doc subpackage for big packages ? I think it may be
> interesting for package that have a lot of documentation and that are
> part of an ecosystem (ie, gems required for other packages like
> gitorious)
I certainly think -doc subpackages are of use, but from what to dictate any
conditionals where and when to create such is something I'm not 100% on (I've
added support to gem2rpm to do it for files specified as documentation by the
gem metadata though), nor on *how* (should it be done by gem2rpm,
or perhaps automatically during package build from the metadata, in
similar fashion
as proposed for -devel packages above?), I'm able to implement (or
provide help in
doing so) the request once the desired behaviour has been figured out though. ;)
>
> Normally %gem_* macros should take care of that, but we might have to
> make it evolve.
I think either way one should anyways try to keep as much as possible out of the
.spec files, leaving as much as possible up to macros, wrappers, dependency
extractors etc. to take care of. It'll help reduce maintenance work on
the individual
packages and help improve compatibility with other distributions.
>
> Do you see something I haven’t thought of ?
>
> I will provide an example spec in this policy in the following days, and
> will take care of making the necessary changes to the existing packages
> once we agree with the above points.
Be sure to have it generated with gem2rpm, and try integrate the
policy back into
gem2rpm again, I've created a public repository for my fork at:
http://gitorious.org/rpm5distro/gem2rpm5

(I might've added some additional confusion in trying to answer some of this,
don't be afraid to ask on things where I don't make sense;)
--
Regards,
Per Øyvind