On Thu, Oct 18, 2012 at 04:50:04PM -0400, Mike Gilbert wrote:
> On Thu, Oct 18, 2012 at 3:29 PM, Brian Harring <[email protected]> wrote:
> > On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote:
> >> Regarding your /usr/bin/python3.2 /usr/bin/sphinx-build example:
> >> invoking python on a binary (or a symlink to a binary) isn't going to
> >> work at all. So I don't see how you've solved that issue.
> >
> > Kindly provide reasoning/justification for such a claim in the future-
> > saves a round of email ping/ponging, and saves me getting pissy
> > towards people if they persist in it. :)
> >
> > Lecture aside, "nuh uh, it does work!" is appropriate. I already
> > hacked up a prototype locally that works fine and does this via an
> > env passing hack- w/ what was proposed, this can be done w/out those
> > hacks, and would be faster.
> >
>
> When you invoke a command like:
>
> /usr/bin/python3.2 /usr/bin/somebinary
>
> The python3.2 program assumes somebinary is a python script and tries
> to parse it. Since somebinary is actually an ELF object, python bombs
> out immediately.
>
> Am I missing something fundamental here?
Nope, you've got me embarassingly, absolutely fricking dead to rights
on that one; I overlooked at the prototype I did was a python script
for 'somebinary', which worked via the env passing.
Would've spotted it upon implementing it in c to say the least, but
still, *cough*. ;)
As you mentioned in a separate email; if we stick a wrapper in front
of the python binaries, that would fly; I don't much like that
however.
Offhand... and this makes it a bit more complex, but still tenuable
imo, but we could get around this via shoving the symlink pathway into
the shebang itself.
scenario 1:
Script gets installed for 2.7, 3.1, 3.2; ignoring the shebang, it's
exactly the same md5 (meaning we can dedup it). The shebang instead
of being /usr/bin/python-whatever, instead is the symlink pathway I'd
referenced. Meaning it would be
/usr/libexec/python/2.7/3.1/3.2/wrapper . If that script was
sphinx-build, this means that sphinx-build{,-{2.7,3.1,3.2}} are all
valid python scripts- they can be invoked either via /path/to/script
or ${python} /path/to/script. There's a few details to sort there,
but nothing egregious best I can tell- implicit in this proposal is
that the wrapper would be smart enough to tell in which context it's
being invoked (sphinx-build vs sphinx-build-2.7).
Scenario 2:
2.7, 3.1, 3.2 are in play; they do /not/ dedupe to the same content,
meaning we actually need indirection in 'sphinx-build' (but not
sphinx-build-{2.7,3.1,3.2} although we would dedupe where possible
mind you).
In that case, to support python3.2 sphinx-build, we'd need a python
script that does the searching/re-exec for the wrapper. This can be
standardized- just have it search for sphinx-build-${PYTHON_ABIS} to
identify the installed versions, then do the usual active
version/epython trick to decide which to use. This honestly isn't too
far off from what we have now.
We can however optimize that; same trick, for the wrapper the shebang
isn't /usr/bin/python; it's just a c version of the python script,
done in c for speed.
So... caveats. If we screw w/ the shebang like this, file isn't going
to like it- it'll fail to identify certain scripts as python. That
said, it's worth keeping in mind that if we use the symlink route, a
file /usr/bin/sphinx-build would result in ELF, vs file
/usr/bin/sphinx-build-2.7 being python.
This can be fixed via an additional rule added to the magic db.
Pretty straight forward, and eselect-python (once it gets these
wrappers) could level an appropriate dep to ensure that's sorted.
So... my preference is shebang; it's basically an extension of the
symlink trick I'd originally mentioned, just cleaner imo.
What are folks thoughts on that?
~harring
