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

Sat Jan 8 11:02:17 CET 2011

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>
+