Jump to: navigation, search


287 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.
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

Navigation menu