Hello. I suggest removing the python-missingos modules from the portage tarball because it is no longer needed. Plus of that it makes bootstraping portage from different CHOSTs (ex. from i386-pc-linux-gnu to i686-pc-linux-gnu) very difficult. thanks.
I've removed the compilation of python bytecodes and the missingos module from the ebuild.
It's definitely not needed? As far as I know, it is required for older versions of OS X. (10.3 and later has lchown?)
The python docs specifically state "Availability:Macintosh, Unix. New in version 2.3" for lchown(). The last time I checked, they are using >=python-2.3 on ppc-macos. If not, their depgraph would already by broken by portage's >=python-2.3 dependency.
Just in case, I'm going to add it back into the ebuild and make it conditional on userland_Darwin.
Nevermind. I see that missingos has been conditional on ! use userland_Darwin, so apparently it's not a problem...
Hmm.. fair enough. When was it for then? 2.2, I guess.. I have seen cases where a python that was meant to have lchown didn't though. That's the main reason why I made it always compiled. Could probably circumvent that just by aliasing lchown to a noop if it isn't available...
I've just noticed that the 2.0.51.22-r3 ebuild detects the absence of lchown and builds it only if necessary: python_has_lchown() { [ "$(python -c 'import os; print "lchown" in dir(os)')" = "True" ] } That seems like a nice approach. The idea of having a silent noop kind of bothers me...
Bug #42461 and bug #89434 are examples of what I was talking about, but after reading through them you're probably right about the lack of noise.
I've add a noisy noop lchown in svn r3466-r3467. It will only be used if python has no lchown and missingos is unavailable. That way, if one of those bugs happens again, the user can simply rebuild python after seeing the warning message.
