Fix #26 and #27.

[leycec]

This pull request fixes #26 and #27, as well as correcting a variety of unrelated issues.

To fix #26, the python_single_target_python3_3 and python_single_target_python3_4 USE flags have been added. For consistency with profile defaults, the former has been enabled by default. These USE flags are not intended to be explicitly set by users; they exist only to solve #26, a well-known (and unfortunately unsolved) issue with the python-single-r1 eclass. Since the existing python USE flag remains disabled by default, this change only affects users enabling the python USE flag.

Relatedly, ebuilds inheriting a python*-r1 eclass (e.g., python-r1, python-single-r1) must embed ${PYTHON_REQUIRED_USE} in the REQUIRED_USE global. So, we do that too.

To fix #27, all remaining instances of /usr/lib have been replaced by /usr/$(get_libdir). And that's it.

A variety of unrelated issues includes:

• repoman complaints, including:
  • Undocumented USE flag armvfp, which metadata.xml now documents.
  • Use of ${PN}-${PV}, which should simply be ${P}.
  • Outdated copyright "Copyright 1999-2014", which should be "Copyright 1999-2015".
• Gentoo Prefix fixes, including:
  • Replacing the / prefixing every absolute path by ${EROOT}.
  • Replacing ${D} by ${ED}.

I'd like to heartily thank you for the tremendous work you've invested into RetroArch on Gentoo. As a fellow overlay maintainer, I can only evisage how much time, blood, and tears this must have cost you.

From the bottom of my nostalgic gaming heart: thank you.

[stefan-gr]

Python is a pet peeve of mine, i'm never sure if i have done it right or not.
I hope to find a cleaner solution to that problem some day since i don't really want to force users to manually disable use expands when they eselect a new python version. I'm not notified of changes to the default profile so i will have to guess when to update the python requirement.
Oh well, that will have to wait until i have more free time to read through the python eclasses.

I was certainly surprised that i didn't use get_libdir in the retroarch build, good catch.

• I wish the metadata.xml would be useful in an overlay scenario but i never could figure out how to make euses and similar tools use it. At any rate it should be properly set up, thanks.
• Good find with the ${P} i will do that for all the other ebuilds too.
• My repoman never complaints about copyright, i guess it is too busy reporting bad dependencies (which i should fix...)
• I wasn't aware that gentoo has a special prefix project, that's pretty interesting. After reading a little about it i guess those variables should be compatible since EAPI=3 so it shouldn't hurt to use them. Shouldn't ${EROOT} also be used in all the other insinto functions?

All in all i'm pretty stoked with the changes you made, especially the python fixes. I appreciate everyones effort providing fixes for the ebuilds.

From the bottom of my nostalgic gaming heart: thank you.

You're more than welcome.

[leycec]

Python is a pet peeve of mine, i'm never sure if i have done it right or not.

I couldn't agree more. The Python 2/3 split made trouble for every Linux distribution, but the pain seems to be particularly pronounced on Gentoo. I don't necessarily blame Gentoo developers for this one; given the frankly limited facilities of Bash, conditionally supporting multiple concurrent installations of Python was never going to be easy.

I just wish the new Python eclasses weren't so fragile. They're well-documented, but I'm not convinced that anyone knows how to use them properly. I don't!

I hope to find a cleaner solution to that problem some day since i don't really want to force users to manually disable use expands when they eselect a new python version. I'm not notified of changes to the default profile so i will have to guess when to update the python requirement.

Yup. It's a terrible hack any way you look at it. What's wild is that this appears to be the officially accepted solution. For example, the official Portage version of media-sound/gnome-music contains the following:

inherit gnome2 python-single-r1
...
# Let people emerge this by default, bug #472932
IUSE+=" +python_single_target_python3_3 python_single_target_python3_4"

Oh well, that will have to wait until i have more free time to read through the python eclasses.

I can't recommend that. I think I'm getting a headache already.

I wish the metadata.xml would be useful in an overlay scenario but i never could figure out how to make euses and similar tools use it. At any rate it should be properly set up, thanks.

Absolutely. Overlay support is half-baked at best – and pretty much always has been. I don't quite understand why layman hasn't been merged into emerge, myself. Most other package managers have built-in support for that sort of thing. Ubuntu's apt-get, for example, supports Personal Package Archive (PPA) repositories out of the box.

My repoman never complaints about copyright, i guess it is too busy reporting bad dependencies (which i should fix...)

I laughed so hard at this. I may have cried a little.

I wasn't aware that gentoo has a special prefix project, that's pretty interesting. After reading a little about it i guess those variables should be compatible since EAPI=3 so it shouldn't hurt to use them.

Yup. Gentoo Prefix is pretty awesome. It's like Python's virtualenv, only for the entire distribution. And hence way cooler.

Shouldn't ${EROOT} also be used in all the other insinto functions?

Good question. The answer is "No, thank God." But I'm glad you noticed that. The reason why you don't need to use Gentoo Prefix variables (e.g., ${EROOT}, ${EPREFIX}, ${ED}) here is that all of the stock installation functions defined by /usr/lib/portage/python3.3/phase-functions.sh already do so. For example, here's the definition of insinto():

insinto() {
    if [ "$1" == "/" ]; then
        export INSDESTTREE=""
    else
        export INSDESTTREE=$1
        if ! ___eapi_has_prefix_variables; then
            local ED=${D}
        fi
        if [ ! -d "${ED}${INSDESTTREE}" ]; then
            install -d "${ED}${INSDESTTREE}"
            local ret=$?
            if [[ $ret -ne 0 ]] ; then
                __helpers_die "${FUNCNAME[0]} failed"
                return $ret
            fi
        fi
    fi
}

Note the ${ED}. Pretty cool, eh?

I appreciate everyones effort providing fixes for the ebuilds.

Man, I so appreciate you maintaining these ebuilds. I can't imagine how much time this must have taken. But when I see that sweet "Ninja Gaiden" intro over and over again, it'll all be worth it. (8-bit cinematography: there is nothing better.)

[stefan-gr]

I can't recommend that. I think I'm getting a headache already.

Perhaps it is better for me to just let it be.

Absolutely. Overlay support is half-baked at best – and pretty much always has been. I don't quite understand why layman hasn't been merged into emerge, myself. Most other package managers have built-in support for that sort of thing. Ubuntu's apt-get, for example, supports Personal Package Archive (PPA) repositories out of the box.

The repos.conf changes some time ago give me slight hope that it is not far away that we can completely remove layman. It's just used to add overlays nowadays and portage can completely take care of syncing them. It's just too bad that the metadata.xml is still useless.

Note the ${ED}. Pretty cool, eh?

I really hoped that was the case and am now content with my life. Just a little bummed that nothing of this is mentioned in the ebuild writing docs, especially the variables guide.

Man, I so appreciate you maintaining these ebuilds. I can't imagine how much time this must have taken. But when I see that sweet "Ninja Gaiden" intro over and over again, it'll all be worth it. (8-bit cinematography: there is nothing better.)

Just a little bit too much time and a beer is all it needed (dat cleaning up though...). Sadly i don't have as much time is i would like, especially for better arm support. But thanks to others it makes progress. I hope you have a fun time relishing in the past glory.