handling interpreters in *-snapper scripts (or snapcraft)

[Michael Terry]

On Mon, Jun 15, 2015 at 8:57 AM, Didier Roche <didrocks at ubuntu.com> wrote:

> Le 15/06/2015 14:54, Oliver Grawert a écrit :
>
>> hi,
>>
>> Am Montag, den 15.06.2015, 08:47 -0400 schrieb Michael Terry:
>>
>>> Why not instead of a runtime solution, you just have py-snapper go
>>> through and adjust all shebangs right before creating the snap?
>>> -mt
>>>
>> this was my fallback idea ... but also the ugliest of all solutions (and
>> possibly error prone)
>>
>
> That would solve, 90%+ of the existing issues, I agree. If we only focus
> on those, that makes sense.
>
> However, I can clearly see some apps doing some kind of:
> subprocess.call(["/usr/bin/python", "foo"])
> Should we care of those use cases? That's the real question I guess…


(we could probably also find and detect such cases in Python code -- but
they might be doing that in a C module or some such, agreed)

At some point, you have to scope the thing.  We can't fix everyone's
hardcoded path code (which is often a bug, especially if "/usr" is the
prefix used).

If we really want to be able to run 100% of our in-archive compiled code,
we need a solution like overlayfs or deb2snap.

But if we're just talking "helping a maintainer package things up" then I
think it's fine to fail in some corner cases where the maintainer can just
fix their hardcoded-path bug anyway.

-- 
-mt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150615/251ace94/attachment.html>