For all the people who might be interested, I recently created a shell script to automatically install ROOT on the most common operating systems (Ubuntu, MacOS or Windows WSL). It has been tested on Ubuntu and Windows for the moment and it works well. You can also choose which installation method you prefer (binary, source etc…); some less common methods, like Conda installation, are not supported so far.
The script can be found at my github page: JustWhit3 / root-framework-installer
I created this script because I am the tutor of a ROOT course at my university (Laboraorio di Elettromagnetismo e Ottica [Modulo 3] at University of Bologna) and I have seen many people struggling with this installation. Therefore I thought it would be good to help newbies also indireclty. I also wrote some guides (on GitHub: JustWhit3 / useful-guides), trying to mention all the issues that may appear during installation, in order to help people installing it manually if they prefer.
Let me know what do you think about it (feel free to open issues on GitHub of course).
There is a long-standing problem with the “.tar.gz” binary distributions provided by the ROOT Team . Each of them relies on some set of system packages (compilers and libraries). Unfortunately, there is no place where these dependencies are explicitly listed.
Some time ago, I tried (and failed) to convince the ROOT Team managers to help people with it.
In your “install.sh” script, you have a procedure that installs the packages needed by the “current” ROOT release. But, this procedure (and the list of packages that it uses) is “Ubuntu 20.04 LTS” specific (so, it works for the “current” WSL, too, but it will not work with other Ubuntu versions nor with different Linux flavors).
@Wile_E_Coyote taking into account my experience with students, I automatically set the download of all this packages during the installation procedure with the script (in particular for Ubuntu and WSL). The problem has been solved thanks to this for many students.
If you look into the source code af my script you can find the complete list of packages you mentioned.
@Wile_E_Coyote answering to your edit: yes, it is true, in fact as I wrote, this installer is supported for Ubuntu only Linux flavour (for now). For what regards the list of packages: it should be enough for any Ubuntu version (in fact it has been tested not only on Ubuntu 20, but also on older versions, you can try yourself if you want). The script ensures you also have the latest version of the package / compiler, otherwise it will upload it.
However, if anyone of you find issues or suggest improvements, he/she can open a GitHub issue or send a pull request of course.
I think it’s hard to try to do and maintain a generic script**, even if it’s only Ubuntu --different versions of Ubuntu may have different requirements, since even package names change sometimes, e.g. a given tool being provided by a different package in a new version. Sure, dependencies are listed here, but you will need to check and perhaps update your script with every new ROOT version, and that’s without counting ‘unexpected’ needed stuff (I might be wrong and it’s not really unexpected, but see for example my second point below), which you would miss unless you follow the posts in this forum, or get these reports somehow. But it could be a convenient alternative for some users.
In any case, a couple of suggestions for your script (I don’t use GitHub, so I put them here):
- In the Ubuntu section, you should do first sudo apt-get update and then upgrade, i.e. swap lines 137 and 138.
- At least for WSL, maybe this should be added too:
sudo apt-get install libgsl23 (see this post).
- Minor suggestion: apt instead of apt-get, although that’s for Ubuntu >= 16.04
** I do have my own script to install all the packages and ROOT dependencies I usually want in my Ubuntu, but I always check it before using it on a fresh install, to catch any changes 
First of all: thank you very much for the suggestions @dastudillo . I added some missing packages to the installer, and improved a bit the script using your hints.
For what regard the dependencies, yes, at this point you are right. The fact is that this script has been created for newbies and therefore the “elementary” list of packages should not change too much from a version to another (I think). I mean, the “classic” packages are often enough (if their name doesn’t change of course). But I understand that if you are an intermedium / advanced user maybe you are interested in gettin’ all of them, of course.
However, I plan to keep my eyes on the new ROOT dependencies web page, in order to catch possible changes and, at that point, to improve the script.
Maybe I could create another script which reads the dependencies directly from the website and then copies their name in the installer script. Not easy, but I could try to implement it in future.
Thank you again for the hints, really appreciated.
PS: I added your user name (and a link to your ROOT user page) to the indirect contributors list on GitHub, since you helped me with this tips.
1 Like
BTW. With the recent ROOT releases, you’d better install both (on “Ubuntu 20.04 LTS”): “python3-dev python-dev”. If you want just a single python version then: “python3-dev”.
Thanks also to you @Wile_E_Coyote . I added your corrections too.
Hi Gianluca,
thank you for sharing!
As a side note, on Ubuntu ROOT can be installed as a Snap package (see e.g. Installing ROOT - ROOT), which also automatically brings in the dependencies.
Cheers,
Enrico
Hi @eguiraud,
Yes I know, but (at least for me) snap didn’t installed it correctly (in fact the snap ROOT version is maintained by others, not by the official ROOT developers, if I am not wrong). I had issues with snap, as well as my students. Therefore I developed the script to fix these issues and to add a new feature (which snap installation doesn’t have) to let you choose the installation method and platform also.
Cheers,
Gianluca.
Snaps don’t work on WSL because WSL doesn’t use systemd as an init system, and snaps are currently dependent on systemd to handle a lot of the implementation behind them. WSL can be tricked into making it work, but it’s not something I’d recommend.
In full-fat VM’s, the snap would work quite fine. So if we analyse this as a problem of user experience and we’re willing to drop WSL2 as the backend, you can get other interesting solutions such as using e.g Multipass which in essence provides a WSL like environment but doesn’t skim on the features. With approaches like that you could even go so far as to provide a cloud-init file describing the entire state of the environment you’d want (user accounts, packages, etc), and the software would handle the entire setup for them (without having to resort to e.g, making a single image that’s never updated).
Still, if there’s any other issues aside from actually getting it installed, I’d be welcome to hear them; there’s a lack of feedback in general, there’s only been a few posts in the past year on these forums about it. I can’t fix it for everything because the limitations of the package format, but users new to ROOT such as students are entirely the target demographic, so if there’s issues there I’d be willing to take a look at what can be done.
The positive feedback is rarer than the negative feedback, but I do get some; and there’s also the usage stats to look at, so I think I’ve done a good job for the target audience at the very least
Hi @James-Carroll sorry if my comment might has been interpreted as offensive, I didn’t mean that the snap installation is bad, but simply that I and others found issues, expecially in WSL. That’s the reason for the existance of my script, which of course is far from being perfect. In fact, it is a script wrote only for a certain kind of users and it may also fails with others (due to dependancies or other stuff).
I don’t remember the exact issues I got with snap, since I tried to install it 1 year ago, but if I encounter them again I’ll report you as soon as possible, of course.
Don’t worry, I didn’t take any offense I guess I just like being verbose, so I apologise back if that seemed like I was reacting defensively!
The fact it doesn’t work in WSL bothers me too, because I’d really like if it did, and I can completely understand that students are keen to use the WSL environment, it is a good environment for the majority of use cases; it’s just a shame that it lets down in some niche areas such as systemd/snaps (which I happen to personally experience more than the average user!). You’re focusing on the user experience, which I get entirely, because it’s what I’m aiming for too, technical approach aside.
I do like the work you’ve shown here, anything that makes the process easier for people is of course always welcome! And thanks for offering to report the snap bugs if you decide to try it out again in the future 
1 Like