2011/1/7 Remy CLOUARD <shikam...@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