handling interpreters in *-snapper scripts (or snapcraft)

Joe Talbott joe.talbott at canonical.com
Mon Jun 15 14:43:11 UTC 2015


On Mon, Jun 15, 2015 at 10:06 AM Michael Terry <michael.terry at canonical.com>
wrote:

> On Mon, Jun 15, 2015 at 9:56 AM, Oliver Grawert <ogra at ubuntu.com> wrote:
>
>> if /usr/bin/python is a wrapper instead of the actual interpreter that
>> then executes $SNAP_APP_PATH/usr/bin/python, you would cover all
>> cases ... but that would indeed mean one such a wrapper per possible
>> interpreter shipped inside the core image ...
>
>
> That feels uglier to me than modifying shebangs at build time, but beauty
> is in the eye of the beholder.
>
> More specifically, it feels very unsnappy.  We'd be catering to old-style
> code that either is buggy (in case of upstreams with /usr hardcoded) or
> written for another platform (in case of deb files that can rightfully
> assume /usr).  Plus, it encodes expectations into the core image about how
> snaps lay out their files.
>
>
I agree.  I think it's a slippery slope to special case the list of
potential interpreters in the core.  Is it possible to do the interpreter
wrapper(s) in frameworks?

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150615/91ad17a4/attachment-0001.html>


More information about the snappy-devel mailing list