Problems trying to create a snap package for bioinformatics tools

[Didier Roche]

Le 24/10/2016 à 16:13, Gordon Ball a écrit :

> Hello

Hey Gordon,

> 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]

Nice way to ship latest to xenial users! Thanks for this 

> 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.

Interesting use case 
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 /home/*). It worthes tracking it!

>  * 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?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161024/eea31128/attachment.html>