* Package name : root Version : 6.22.06 Upstream Author : CERN <https://root.cern/> * URL : https://github.com/root-project/root * License : LGPL-2.1 Programming Lang: C++ Description : open-source data analysis framework The ROOT system provides a set of OO frameworks with all the functionality needed to handle and analyze large amounts of data in a very efficient way. Having the data defined as a set of objects, specialized storage methods are used to get direct access to the separate attributes of the selected objects, without having to touch the bulk of the data. Included are histograming methods in an arbitrary number of dimensions, curve fitting, function evaluation, minimization, graphics and visualization classes to allow the easy setup of an analysis system that can query and process the data interactively or in batch mode, as well as a general parallel processing framework, PROOF, that can considerably speed up an analysis. Thanks to the built-in C++ interpreter cling, the command, the scripting and the programming language are all C++. The interpreter allows for fast prototyping of the macros since it removes the time consuming compile/link cycle. It also provides a good environment to learn C++. If more performance is needed the interactively developed macros can be compiled using a C++ compiler via a machine independent transparent compiler interface called ACliC. The system has been designed in such a way that it can query its databases in parallel on clusters of workstations or many-core machines. ROOT is an open system that can be dynamically extended by linking external libraries. This makes ROOT a premier platform on which to build data acquisition, simulation and data analysis systems. I want to maintain ROOT in the science team. ROOT was already in Debian as `root-system` [1], but hasn't been updated since 2015. I will probably go with a more easy maintainable route like I did with Geant4 for the start and do package splitting later. [1] https://tracker.debian.org/pkg/root-system
[...] Please re-use the old name. "root" is a terrible choice of package name. Thanks, Julien
Quoting Stephan Lachnit (2021-01-26 16:34:14) Please add prefix "cern-" to the package name - both source and binary packages. - Jonas
Julien Cristau wrote...
At least. Even "root-system" is not very distict, I'd rather choose
something like "root-analysis-framework", assuming that name is a good
description for what the package does.
Christoph
Control: retitle -1 ITP: cern-root -- data analysis framework I agree with you all, the name is case-insensitive not very unambiguous. I'm not a big fan of `root-system` either, as I think it's ambiguous as well and doesn't really describe the software. I'll go with `cern-root`, that should be pretty unambiguous. Regards, Stephan
Steffen Möller <steffen_moeller@gmx.de> writes: +1 FYI, the following is the previous CERN ROOT changelog. The old name was root and changed to root-system since 5.15.07-1. http://metadata.ftp-master.debian.org/changelogs/main/r/root-system/unstable_changelog Benda
tbh I'd just keep root-system only for consistency with the past. However I have another concern, rather than the name: that makes it more or less maintenable IMHO. Actually, IME it's often a more split package that might be somewhat easier to maintain. The problem really is about somebody who can dedicate a long time to it, not just one or two years. For reference, just looking at tracker: * added in 2007, but the maintainer was immediately unavailable next year, so there were NMUs starting in 2009 not even 21 months after the first upload. Removed in 2011 since nobody seriously picked it up * re-added in 2012, the maintainer looked motivated and clearly did quite a few uploads to maintain it, but that winded down in 2014, and after a bunch of NMUs was removed in 2016 (18 months after the last upload and 11 months after being removed from testing, so you can really just think of it as removed in 2015) So history of this package shows that the interest wanes after ~2 years, which meakes me wonder wether this is only driven by some external factor, like some phd-driven work or similar. I'm *not* in favor of adding such big piece of software to the archive, if it's interest is something that is assured to disappear in a couple of years. So please make sure of your motivation and state it. You've been a DM for less than a year and you are already doing the NM to become a DD, so I really hope the above history of src:root-system doesn't happen again, at least not that quickly :)
ROOT builds more than a dozen of libraries, even more than Geant4. Since splitting packages takes a significant amount of time (the entry in control is basically copy and paste, but creating the .install file isn't that fast), this takes more than 5 minutes (speaking from experience with Geant4). In Geant4 I also had the problem that lintian went completely crazy because it couldn't find the libraries from the other packages. Since the previous package is so much older, I won't even trying to work with these files - so much changed it's easier to start from scratch. I'm not saying I'm not doing it eventually, but for now packaging ROOT really has different problems. It installs .exe's to /usr/bin, ships tons of builtin libraries and also has some other terrible design choices in terms of its build system. For me packaging is also driven by the fact that I need it for my studies, but I don't think that's a problem. It's not different for my other packages as well. I will probably study physics for at least another 3 years, but I obviously can't promise I'll loose interest in packaging it eventually. Regards, Stephan
I've decided to go with root-framwork. The reason for this is that this is also the name for the package in the snap store, which afaik was created from some authors of ROOT, so I think it's best not to come up with something new again. Progress on the other hand is a bit slow at the moment, the main reason is that I wait for the 6.24.xx series to release, which includes an important build system fix that I don't want to backport (it's hard-freeze time anyway so need to rush). Regards, Stephan
now on Salsa [1]. Let me know if you have issues with building. The following things still need to be done, orderd after importance: - write a DEP-5 copyright - remove builtins from the source tarball - split the package sanely - understand linking of libRInside.so - package UNU.RAN [2] - package VDT [3] - package VecGeom [4] - update Pythia8 [5, 6] Some notes: the usual library splitting is basically impossible for ROOT. There are several reasons for this, one being the insane amount of libraries, 142 to be precise. Some of them also have very general names like "libGui.so". The other reason is that ROOT works less like boost, which also has a lot of libraries, and more like one interwoven network of libraries where you want to have all (or at least most) of them. For these two reasons, libraries are installed to lib/multi-arch-triplet/root instead of lib/multi-arch-triplet, and a config for ld.so is added to pick the libraries up. This isn't ideal of course, but better than the alternative. Splitting thus will be more centered around additional dependencies, like for example the Python interface of ROOT. But I haven't started with that yet. The most important and still missing work is the DEP-5 copyright file. ROOT has tons of files, and looking through them will take a significant amount of time. ROOT also includes some thirdparty dependencies which we don't want and need to remove from the source tarball. Since I'm wiriting my Bachelor thesis at the moment, I don't have time for this anytime soon. If someone wants to help with that, I would appreciate it. Besides this, I'll still have to figure out how to properly link against the R library, one mail to the R team is probably enough but I haven't done it yet. All important dependencies are already packaged in Debian, but there are some features that require additional dependencies. UNU.RAN can be used for random number generation, but I haven't looked at the code yet at all. VDT can be used for fast vectorized function, but the CMake build file require some heavy modification to be actually usable. VecGeom is relatively straight forward to package and I will probably upload it in the near future, it is used for vectorized geometry. Pythia8 is a Monte-Carlo event generator, the package is in Debian, but completely outdated and unmaintained. - Stephan [1] https://salsa.debian.org/science-team/root [2] http://statistik.wu-wien.ac.at/unuran/ [3] https://github.com/dpiparo/vdt [4] https://bugs.debian.org/988526 [5] https://tracker.debian.org/pkg/pythia8 [6] https://pythia.org/
Hi Yadd, Thanks for the initial packaging of OpenUI5! I noticed that the installed source is not optimized. I'm not sure how this relates to real-world performance. ROOT histograms can contain a lot of data, so this could be an issue. I've taken a look at the lintian output and let's just say it's not pretty. Since I currently lack the time to take a look at it, I decided to delay this feature of ROOT (it can be built without support for OpenUI5). The usage of OpenUI5 is a feature of the still experimental ROOT v7 components, so I will focus on the ROOT v6 components first before tackling this issue. Regards, Stephan
OK, I compared only what was provided by `npm install @openui5/foo` and what was in source tree Cheers, Yadd