Changes

Jump to: navigation, search

Ruby-kit

381 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 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.''' {{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.) This means that getting dynamic changes from USE changes is "safe" from a Portage perspective. {{c|USE_RUBY}} is an ebuild setting, which is hard-coded into each ebuild. The This is also OK -- no problems here. But the Ruby eclasses cannot 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 eclasshere is why. These dependency changes Ebuild dependencies get written to the Portage ebuild md5-cache. The Portage ebuild md5-cache can detect when eclasses have been changedvia their digest (md5 hash, ) 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 this design, settings in profiles that have the potential of changing are not allowed to "influence" the eclass directly. Eclasses are just allowed to "augment" things like dependencies in an ebuild based on their own, self-contained logic. 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 need to have hard-coded logic or values in the eclass so 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.
 
{{Note|The current rule for Portage is that dependencies in packages must be defined in the ebuild itself, and may be modified by eclasses. But eclasses cannot be 'influenced' by profile settings, because Portage is unable to detect these changes and invalidate its internal cache.}}
There is no trivial solution to this that I am aware, but there are potential solutions:
Bureaucrats, Administrators, wiki-admins, wiki-staff
6,633
edits

Navigation menu