New packaging guidelines for Ruby
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