New packaging guidelines for Ruby

Vít Ondruch vondruch at redhat.com
Tue Feb 28 11:39:14 UTC 2012


Hi,

since I was not subscribed to this mailing list, I starting new thread 
in Hope to move forward with the packaging guidelines. There are still 
some outstanding issues.

= Mandatory rebuilding gems =

Yes, Ruby SIG is still against it, since there is known just one gem ATM 
which needs such treatment. Now I list several pros/cons:

Pros:
* It would allow ruby packages to follow the same steps as other packages.

Cons:
* More overhead for maintainers.
* More confusion for new-commers, since this approach is not know in 
Ruby community and there is no best way how to achieve it.
* There is only one known gem in Fedora, which needs this treatment ATM.
* If you need patch binary part of gem, it is sign that the gem is not 
well maintained by upstream, otherwise it would not be needed.

= Vendorlib =

It is not good idea to move vendorlib out of the Ruby directory 
structure. Actually it is pair of directories, vendorlib and 
vendorarchlib. These directories are typically used by libraries Ruby 
bindings, such as geos, subversion, etc. This platform dependent 
bindings has no meaning to other Ruby implementations, such as JRuby.

= ruby(name) vs rubygems(name) =

Although we want to see as much libraries as possible provided in a gem 
form, there still be some libraries which are not gemified. However, 
Gemifies library *should not* always provide also ruby(name) virtual 
provide, since these are not always simply interchangeable. Gem caries 
with itself its metadata. When gem is loaded to Ruby's library path, 
this metadata are processed as well and it might put some other 
dependent libraries to Ruby's library path as well. In contrary, the 
ruby(name) provide will mean that it is not gemified library, so I would 
prefer to stay with distinction between ruby(name) and rubygem(name). 
Gem would provide the ruby(name) only in case it obsoletes previously 
available ruby library.

These are 3 concerns I remember was the most controversial. Please feel 
free to share your thoughts.


Vít


More information about the ruby-sig mailing list