I don't know in how many eclasses similar constructs exist, but as of April 27, 2018 the ruby-ng.eclass had ruby:2.2 removed from the list of accepted RUBY_TARGETS. The result is a nasty error in portage that cannot be recovered from without manually changing files in the portage tree or when the (arch) dependency that triggered the user's restriction on RUBY_TARGETS has seized to exist. Also note that make.defaults for the following architectures conflict with the forced constraints set by this eclass: x86, arm64 (ruby21), arm, hppa, alpha Again I do not know whether these defaults still make sense, but obviously they must have done so at some point. The constraint set by the eclass therefore potentially wrecks quite a lot of systems. Reproducible: Always Steps to Reproduce: 1. install ruby:2.2 (if needed override current masking or revert to April 26 tree) 2. set `RUBY_TARGETS="ruby22"` in /etc/portage/make.conf 3. make portage tree current 4. run world updates with --newuse Actual Results: !!! The ebuild selected to satisfy "dev-ruby/coffee-script" has unmet requirements. - dev-ruby/coffee-script-2.4.1::gentoo USE="-test" RUBY_TARGETS="-ruby23 -ruby24 -ruby25" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( ruby_targets_ruby23 ruby_targets_ruby24 ruby_targets_ruby25 ) --> exit error Expected Results: list of packages to update ... !!! The following installed packages are masked: - dev-lang/ruby-2.2.10::gentoo (masked by: package.mask) --> continue updates
While this issue is in fact more of a general issue, it seems to me that as this is being treated as a ruby specific issue and connected to ruby 2.2 there is no point in pursuing this and we can mark this as obsolete. To stipulate the original issue, as a device specific OS maintainer I find fairly frequent frustration in eclasses overriding system forced constraints and/or enforcing stricter requirements for no apparent reason, causing conflicts that a regular user will have a hard time solving when attempting world updates. As I understand eclasses fall under the responsibility of the various maintainer groups, however as these are also part of the portage tree I feel that there should be better communication between you and the portage maintainer group to prevent breakage on systems other than the most common amd64.
(In reply to Gordon Bos from comment #1) > While this issue is in fact more of a general issue, it seems to me that as > this is being treated as a ruby specific issue and connected to ruby 2.2 > there is no point in pursuing this and we can mark this as obsolete. > > To stipulate the original issue, as a device specific OS maintainer I find > fairly frequent frustration in eclasses overriding system forced constraints > and/or enforcing stricter requirements for no apparent reason, causing > conflicts that a regular user will have a hard time solving when attempting > world updates. In general, if you feel there's a pointless change, you're free to ask us about it. But the Ruby eclasses in particular handle this differently to the rest of the ecosystem like Python and Lua. Help would be welcome in maintaining things and input from a different perspective if you're willing to help with the upkeep of older stuff anyway.