New packaging guidelines for Ruby

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux