A quick test shows that currently ruby-ng.eclass is not compatible with EAPI=4: >>> Unpacking source... * Running unpack phase for all ... * Unpacking .gem file... ... [ ok ] * Uncompressing metadata ... [ ok ] * Unpacking data.tar.gz ... [ ok ] >>> Source unpacked in /var/tmp/portage/dev-ruby/racc-1.4.6/work * ERROR: dev-ruby/racc-1.4.6 failed (prepare phase): * The source directory '/var/tmp/portage/dev-ruby/racc-1.4.6/work/racc-1.4.6' doesn't exist * * Call stack: * ebuild.sh, line 2342: Called ebuild_main * ebuild.sh, line 2249: Called dyn_prepare * ebuild.sh, line 1005: Called die * The specific snippet of code: * die "The source directory '${S}' doesn't exist" I have not yet investigated further.
Oh FFS that's not a bloody sanity check is it? =_=
We would really need that support :(
Unfortunately this is very low priority on my own agenda because there are plenty of other things needing more attention in the ruby project. I'm not sure if Diego has any time for this soon, so if you really need this to move forward it might be best to investigate the issue yourself.
The problem is caused by the change in S-WORKDIR-FALLBACK in EAPI=4 (see page 36 of PMS). In older EAPI's the ebuild would fall back to use $WORKDIR when $S was not a directory. Our ruby-ng_src_prepare expects to be in $WORKDIR when it does its magic of unpacking for all desired ruby targets, but right now we don't get that far since our S can't be found even before entering src_prepare. A further complication is that we allow S to be set in the ebuild with special support for a wildcard, in order to handle github downloads more easily. I've added portage to the bug, hopefully they can suggest a good way to fix this.
Created attachment 270995 [details] Patch for make ruby-ng.eclass EAPI=4 compatible This patch circumvents the S-WORKDIR-FALLBACK check in EAPI=4, and uses RUBY_S as a way to influence the unpack path for e.g. github tarballs. Suggestions for cleaner bash are welcome. Also todo: documentation for RUBY_S. @Diego: can you review this?
This fix has now been committed to ruby-ng.eclass, so it is now EAPI=4 aware.
Umm.. This change made to support EAPI=4: _ruby_invoke_environment() { old_S=${S} case ${EAPI} in 4) if [ -z ${RUBY_S} ]; then sub_S=${P} else sub_S=${RUBY_S} fi ;; *) sub_S=${S#${WORKDIR}/} ;; esac ...seems to negate the usage/support of ${RUBY_S} in EAPI<=3 .. was that planned? Alternatively, is RUBY_S a new EAPI=4 thing? Would it be possible instead to simply make the EAPI=4 version of this the default for all EAPI versions?
(In reply to comment #7) > Umm.. This change made to support EAPI=4: > ...seems to negate the usage/support of ${RUBY_S} in EAPI<=3 .. was that > planned? Alternatively, is RUBY_S a new EAPI=4 thing? Would it be possible > instead to simply make the EAPI=4 version of this the default for all EAPI > versions? Older EAPI versions rely on trickery with ${S} itself which no longer works in EAPI=4. Hence the introduction of RUBY_S instead in EAPI=4. I'm not sure what backporting would gain us. Why would you want to do that?
As discussed on IRC this would be helpful for packages with optional ruby support that can't use EAPI=4. Moving this back to CONFIRMED because it might be easy to support this.
Ping, any news on this?
(In reply to comment #10) > Ping, any news on this? I'm not against this but I won't do the work. I'd be happy to review patches.
Closing this as the main issue was already fixed and the backport never happened.
