| 1 |
On Thu, 08 Mar 2012 10:56:21 -0500 |
| 2 |
Michael Orlitzky <michael@××××××××.com> wrote: |
| 3 |
|
| 4 |
> On 03/08/2012 07:03 AM, Michał Górny wrote: |
| 5 |
> >> |
| 6 |
> >> Someone suggested using a standard shebang the last time this came |
| 7 |
> >> up, and if I remember correctly it was one of the |
| 8 |
> >> least-disagreeable solutions proposed. We could of course define |
| 9 |
> >> our own custom format, but I think something like, |
| 10 |
> >> |
| 11 |
> >> #!/usr/bin/eapi5 |
| 12 |
> >> |
| 13 |
> >> would be perfect if we could hand off the interpretation of the |
| 14 |
> >> ebuild to that program. That solves the problem with new bash |
| 15 |
> >> features, too, since you could point that command at a specific |
| 16 |
> >> version. |
| 17 |
> > |
| 18 |
> > And what would /usr/bin/eapi5 do? Are you suggesting misusing |
| 19 |
> > shebang or making ebuilds PM-centric? |
| 20 |
> > |
| 21 |
> |
| 22 |
> I was saying that I'd prefer a more-standard use of the shebang (if |
| 23 |
> possible), rather than defining our own header comment syntax. Either |
| 24 |
> way I think the second option is cleaner than regular expressions. |
| 25 |
> |
| 26 |
> Right now, we're guaranteed the features of bash-3.2. I guess we |
| 27 |
> actually use whatever is executing ebuild.sh to source them. But we |
| 28 |
> need to interpret the ebuild file with something: we might as well |
| 29 |
> put *that* in the shebang, since that's what it's for. |
| 30 |
> |
| 31 |
> So if we were to do this with an ebuild right now, we'd add, |
| 32 |
> |
| 33 |
> #!/usr/bin/eapi4 |
| 34 |
> |
| 35 |
> to the header, and instead of sourcing the ebuild with whatever |
| 36 |
> ebuild.sh is using, we would run it with 'eapi4' and pass whatever we |
| 37 |
> need back and forth. Or maybe ebuild.sh would reload itself using |
| 38 |
> 'eapi4'. If any of that makes sense, the PMS would just need to |
| 39 |
> specify some requirements on the shebang command. |
| 40 |
|
| 41 |
And something will need to provide that /usr/bin/eapi4 thing. And that |
| 42 |
introduces new problems: |
| 43 |
|
| 44 |
1) how are we going to support multiple package managers? will we need |
| 45 |
to install eapi4 thing as a smart wrapper choosing the right PM? |
| 46 |
|
| 47 |
2) what about Prefix? #!/usr/bin/env eapi4 then, or proactive updating |
| 48 |
of shebangs in synced ebuilds? and then regenerating the whole cache |
| 49 |
(guess how long does it take to update it), |
| 50 |
|
| 51 |
3) what should happen if user executes ebuild? the ebuild should merge |
| 52 |
itself? with dependencies or without? |
| 53 |
|
| 54 |
-- |
| 55 |
Best regards, |
| 56 |
Michał Górny |
Archives