The eclass sets S=WORKDIR when eapi4 is set in ebuild. This is quite severe because everyone actually expects the S variable to default to S=WORKDIR/P. This means that if we inherit ruby-ng eclass in eapi4 ebuild we get nasty suprises in phases about not-found files etc, etc... Current workaround is to define S="WORKDIR/P" in the ebuild, but it is ugly as repoman will complain. Please fix your eclas ASAP. Currently you can see the effect of this crap for example in weechat ebuild, just edit one of the available ones and bump eapi to 4 and try to install it.
(In reply to comment #0) > The eclass sets S=WORKDIR when eapi4 is set in ebuild. This is quite severe > because everyone actually expects the S variable to default to S=WORKDIR/P. The eclass doesn't use WORKDIR/P at all so we can't just change that. Also, as far as I can tell from PMS it isn't illegal to change it. > This means that if we inherit ruby-ng eclass in eapi4 ebuild we get nasty > suprises in phases about not-found files etc, etc... Support for inheriting ruby-ng into an ebuild where ruby is only part of the whole package is not very well supported in general. This is only one of the problems. I think that we might need to have a separate eclass to handle that case (or a variable controlling the behaviour in such a way that things also work well in this case). > Currently you can see the effect of this crap for example in weechat ebuild, > just edit one of the available ones and bump eapi to 4 and try to install it. It helps to be polite and not refer to other people's code as 'crap', even if it might be. Looking at the weechat and the build system it support, you should probably not use the ruby-ng eclass at all, since the build system appears to only be able to build against a single ruby implementation. In fact, weechat-9999 is broken since it will always only link against ruby19, despite the fact that USE_RUBY also mentions ruby18.
Removing QAcanfix keyword, because this doesn't look like a problem that could be trivially fixed by QA.
