Jump to: navigation, search


2,977 bytes added, 9 months ago
no edit summary
This gives us the ability to "focus" our Ruby support around specific versions of Ruby.
== Portage Limitations (Technical) ==
To implement all this, the {{c|RUBY_TARGETS}} settings in the profiles must be kept in sync with the forked Ruby eclasses in Core-kit, so that they reference the same Ruby versions. Ideally, we would be able to
set {{c|RUBY_TARGETS}} in one central place, and not keep multiple things in sync. But due to limitations in Portage, this is how it needs to be done.
The reason why we can't set Ruby settings all in one place is because {{c|RUBY_TARGETS}} is a profile setting, which gets USE expanded to {{c|ruby_targets_ruby26}}, etc. {{c|USE_RUBY}} is an ebuild setting, which is hard-coded into each ebuild. The Ruby eclasses use the setting of {{c|RUBY_TARGETS}} to influence the content of {{c|DEPEND}} and other variables in the ebuild. These dependency changes get written to the Portage ebuild md5-cache. The Portage ebuild md5-cache can detect when eclasses have been changed, and when this happens, the cache entries will be invalidated and new data will be extracted from the ebuild to ensure that the dependency values are correct. But the Portage ebuild md5-cache cannot detect when a change to ''profiles'' would impact dependencies. Because of this, settings in profiles that have the potential of changing are not allowed to "enter" the eclass directly, and thus {{c|RUBY_TARGETS}} is not allowed to be simply read and used by the eclass. Doing this would result in the Portage md5-cache containing incorrect information. So we are unfortunately stuck in a position where we need to "keep the beams from touching" and thus we need to have hard-coded values in the eclass. If we change the values in the eclass, then its digest will change, and thus the md5-cache will detect this change and update its cache of ebuild metadata.
There is no trivial solution to this that I am aware, but there are potential solutions:
1. Deprecate {{c|RUBY_TARGETS}}, and have the OS Ruby settings set in the eclass. Now they are defined in one place. This means that users can't override them in {{c|/etc/make.conf}}. The eclasses must live in core-kit for technical reasons, and thus couldn't change automatically if a user changed their Ruby kit. So there are some downsides to this.
2. Deprecate md5-caching, or at least Funtoo-generated cache entries for improved performance. Then a user's local profile settings could be factored in to the md5-cache calculation. This would allow eclasses to interact with dynamic profile settings. It could reduce speed of Portage temporarily since it would need to rebuild its cache more often. If cache regen were fast enough, this wouldn't matter (and Funtoo has much faster cache regeneration code than Gentoo which could be leveraged.)
3. Just deal with the current situation for now, which is at least an improvement. Users don't generally need access to different ruby-kits, except developers when testing, and we have tools for developers to deal with this easily anyway ({{c|merge-kits}}).
[[Category:Official Documentation]]
Bureaucrats, Administrators, wiki-admins, wiki-staff

Navigation menu