Edited:
I’ve removed this request because there was a lot more than the 2 aliases in the previous post revision that need to be considered, and I’d rather push back requesting dozens of aliases right now until it’s clear that it’s even worth doing to begin with.
Thanks!
Feel free to add this request back whenever you consider. Thanks!
I’ve decided to re-request this after looking at the scope of the ROOT framework itself better and starting some dialogue with upstream.
ROOT (https://root.cern) is a framework primarily for physicists working in high energy physics. It’s been around for 25 years and is well known in it’s field. It used to have a package in Debian/Ubuntu with the name of root back in 16.04 but has been dropped since.
Whilst I do have some concern over requesting the first and most essential alias, I think the scope of the snap is very specific and the documentation surrounding the ROOT framework for the past 3 decades relies upon it so none of the users should be confused by the aliases requested. Furthermore, whilst ROOT has GUI functionality and there are some desktop icons in the snap to aid users into opening the terminal correctly, I would expect the vast majority of people to attempt to open it via the CLI at first instance seeing as it is designed to be used as an interactive prompt, so aliases working out of the box is much more essential than for a general desktop app. (It isn’t unusual to use ROOT entirely headlessly).
Every binary bar one (PyROOT) when installed using the official installation methods would be expected by the users to be in $PATH by default, PyROOT itself is not upstream but simply accesses the Python shell in the snap and is needed to run the ROOT Python bindings since the system Python shell cannot be used, so I would like to make a request for:
root-framework --> root
root-framework.pyroot --> pyroot
root-framework.genreflex --> genreflex
root-framework.hadd --> hadd
root-framework.hist2workspace --> hist2workspace
root-framework.memprobe --> memprobe
root-framework.prepareHistFactory --> prepareHistFactory ( Capitalised as is )
root-framework.proofserv --> proofserv
root-framework.rmkdepend --> rmkdepend
root-framework.root-config --> root-config
root-framework.rootbrowse --> rootbrowse
root-framework.rootcint --> rootcint
root-framework.rootcling --> rootcling
root-framework.rootcp --> rootcp
root-framework.rootdrawtree --> rootdrawtree
root-framework.rooteventselector --> rooteventselector
root-framework.rootls --> rootls
root-framework.rootmkdir --> rootmkdir
root-framework.rootmv --> rootmv
root-framework.rootprint --> rootprint
root-framework.roots --> roots
root-framework.rootslimtree --> rootslimtree
root-framework.xpdtest --> xpdtest
There are some other binaries that I cannot declare in the snapcraft.yaml, E.G, rootn.exe; Is it possible for a snap alias to create the alias rootn.exe if the actual app name was rootn-exe or something similar? Whilst it isn’t a deal breaker to not have some of the extra binaries, it would be helpful for consistency to get as much as a complete environment in there as possible. The absolute majority of the functionality of this program for the targetted use case for snaps is probably in root pyroot and hadd, but software with as much history as this tends to have people reliant on every random bit of it.
Thanks for the help
Thanks for the detailed info - +1 from me for all of these as there is no conflict for these names in general, except as you mention in Ubuntu 16.04 for the existing root-framework packages.
Regarding rootn.exe, yes this is possible - I suggest declaring this as a command rootn-exe in the snapcraft.yaml and we can provide an alias as rootn.exe for it.
Can other @reviewers please vote?
Thanks for the response.
Given it is possible to create aliases for the *.exe binaries with their expected names, can I add onto the requests the final missing binaries:
root-framework.root-exe --> root.exe
root-framework.rootn-exe --> rootn.exe
root-framework.rootnb-exe --> rootnb.exe
root-framework.roots-exe --> roots.exe
root-framework.proofserv-exe --> proofserv.exe
The revision currently on the store doesn’t have these apps in its manifest, I’ll go and upload a revision with them included which should be available in a few hours.
As a general question, assuming the aliases are granted, would existing users automatically apply them or is it necessary to push a new revision so that they download a new store acknowledgement?
Thanks again!
Edit: I’ve pushed a revision to the candidate channel with the extra apps included
+1 from me too for the additional aliases. To answer your other question, I believe aliases only get applied to an existing snap when a new revision is installed.
Looks sensible. I checked various aliases to see if any conflicts exist, and I found none. +1 from me.
+2 votes for, 0 votes against, this is now live. @James-Carroll FYI for existing installations the aliases should be updated on the next snap refresh - for new installations it will happen automatically.
Thanks for all the assistance!
I’ll bump up the candidate release to stable since it has the extra .exe app declarations anyway so everyone is covered ASAP.
