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

[Remy CLOUARD]

On Sat, Jan 08, 2011 at 05:07:55AM +0100, Per Øyvind Karlsen wrote:
> 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/
First of all, thanks for your very complete answer. :)
> >
> > 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..
> 
> 
That does make sense as long as we keep both kinds of packaging. But I’m
pretty sure there won’t be many breakages by switching to one kind of
packaging to another, thus it would make sense to have every ruby-foo
package use the gem system, and then, we could choose one or the other
naming scheme.
> >
> > 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.
Well, nothing prevents us from suggesting that change upstream, I think
these changes might be discussed upstream too, but I agree that this
change will only bring little benefit, so I think this won’t change
> > 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}).
I think you misunderstood what I said there, I was thinking about
youri-check, see http://youri.zarb.org/demo/mandriva/
> >
> > 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.
Likewise, can also be discussed upstream so.
> >
> > 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.
100% agree on this.
> >
> > 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
Thanks for the URL, actually I started modifying the erb template in
gem2rpm, but will clone this and make pull request on this one then :)
(and package it as well)
> 
> (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110108/d3a46434/attachment-0001.asc>