Jump to: navigation, search


755 bytes added, 9 months ago
Portage Limitations (Technical)
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. Dependencies "interact" with USE settings via ''conditionals'' which are actually stored in the dependency itself, and in the md5-cache, so dependencies can "dynamically adapt" to USE settings (this is why USE settings are used so heavily by Gentoo for so many strange things.) {{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-- things either will or will not get written based on the logic of the eclass. 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. In other words, Portage expects that "an ebuild's dependencies" come from the ebuild (tracked by md5 digest), potentially modified by eclasses (tracked by md5 digest), and that there are no other external influences. Because of thisdesign, settings in profiles that have the potential of changing are not allowed to "enterinfluence" the eclass directly. Eclasses are just allowed to "augment" things like dependencies in an ebuild based on their own, self-contained logic. Thus, 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 logic or values in the eclassso that Portage can track any changes to this logic. 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:
Bureaucrats, Administrators, wiki-admins, wiki-staff

Navigation menu