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
hadd, but software with as much history as this tends to have people reliant on every random bit of it.
Thanks for the help