<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-html" lang="x-western">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
style="font-family: -moz-fixed; font-size: 12px;"
lang="x-western">
<pre wrap="">Le 24/10/2016 à 16:13, Gordon Ball a écrit :
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Hello
</pre>
</blockquote>
<pre wrap="">Hey Gordon,
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">I have been trying to create a snap package for the `cufflinks` [1]
biofinformatics tools. These are packaged for debian/ubuntu, but the
package is not built for xenial due to issues with boost 1.56-1.59. [2]
</pre>
</blockquote>
<pre wrap="">Nice way to ship latest to xenial users! Thanks for this <span class="moz-smiley-s1" title=":)"></span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">I tried building a snap package (see snapcraft.yaml below - just a
simple `stage-packages` build) on yakkety in order to bundle the
relevant dependencies and then install it on xenial, but I ran into the
following issues:
* Trying to run any of the binaries gives the error
failed to create user data directory. errmsg: Permission denied
This is presumably related to #1592696, but in this case $HOME is on
an NFS mount under /mnt. Probably an uncommon case, but this probably
isn't the only such configuration.
</pre>
</blockquote>
<pre wrap="">Interesting use case <span class="moz-smiley-s1" title=":)"></span>
In that case, I would say open a separate bugs for it. The issue can be
encryptfs, or profiles not supporting $HOME set to /mnt (or something
else to <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>home<span class="moz-txt-tag">/</span></i>*). It worthes tracking it!
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""> * The package contains multiple binaries, and the links in /snap/bin
are named, eg `cufflinks.cuffdiff`, which makes them incompatible with
existing scripts. Additionally, I can't declare `apps:` keys with
underscores in them, so some come out completely misnamed.
Did I miss an option somewhere to better control command naming?
</pre>
</blockquote>
<pre wrap="">No, you didn't miss anything. As you noticed, commands are namespaced by
the snap name. So, there are 2 rules:
* <snapname>.<appname> for general app name
* <snapname> only as a shortcut if snap name == app name
1. If the scripts you mentioned are part of what's shipped inside your
snap, I would advise patching upstream to accept rather relocatable path
(note that we do direct $PATH inside to $SNAP/bin/ and other similar
path, so they should find the "short" name). You can as well ship dummy
wrappers as part of your snap to also handle those use cases if needed
(but again, from call inside the snap)
2/ If the scripts are externals, we started to discuss about ways to
expose different top-level commands to the system. I'm CCing Gustavo
here who may want to share his plans around this.
Meanwhile, way to workaround this latter case are either:
a) adapting your scripts to call the snap command schema
b) ship some redirect dummy shell which will exec the corresponding
snapname.appname, and add the directory containing those scripts to your
user's $PATH.
Also, I don't see any reason why we are preventing underscores in app
name (nothing in yaml prevents key to be underscores). I don't link such
command name in general, but I don't see any good reasons for this.
Gustavo, is that deliberate?
Cheers,
Didier
</pre>
</div>
</div>
</body>
</html>