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
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
