[Rivet] Debian Rivet package w/patches

[cholm]

Hi Frank et al,

Just to give a bit of context: I talked to Andy who's in Copenhagen for 
a rivet Heavy Ion workshop, and asked if you were interested in the 
Debian patches.

On 2018-08-22 18:01, Frank Siegert wrote:
> Dear Christian,
> 
> thanks, that's very interesting! I'll take a look at the patches,
> which I suppose are mainly distribution-relevant and not
> upstreamable(?), and might use some also in my packaging for Arch
> Linux. But is it correct that this is still at version 1.8.3 or
> 2.0.0beta2?


I think the patches are against 2.0beta2.  Sometimes it takes a bit of 
time for Debian to pick up new versions, as stability is an emphasis of 
the Debian project.  However, if upstream (rivet project) decides to 
accommodate some of the things that Debian needs, it can make the delay 
shorter.  In other words, if you add the "debian" subdirectory to you 
repo and collaborate with the debian developers on the content, then the 
release cycle can probably be shortened.

Here's how I see what the patches does and why they are there

- doc-building.patch: Removes the "test" directory from the sources and 
excludes the "debian" subdirectory from being parsed.  The first part is 
probably to not have additional long documentation in the corresponding 
-doc package.

- fix-analysis-plugin-path.patch.  As the set-up is upstream, you 
install RivetAnalysis*.so to <prefix>/lib (i.e., /usr/lib).  This patch 
puts the plugins into <prefix>/lib/rivet (i.e., /usr/lib/rivet).  The 
Debian policy, which adheres to the FSH standard, says that only 
linkable library can be in /usr/lib.  Since the plugins are not linkable 
(or intended for linkage), they should go into a package specific 
directory (i.e., /usr/lib/rivet).

- path-max.patch.  AFAIK FHS is pretty specific about the maximum path 
length, which is why it is defined here.

-  purge-convenient-tinyxml-lib.patch:  Debian prefers to build against 
system libraries rather than embedded codes.  So at build time there's a 
dependency on tinyxml development packages being installed.  At 
(package) install-time, there's an equivalent dependence on the runtime 
tinyxml library package (see also debian/control).

- purge-non-free-fastjet-plugins.patch: OK, this is a bit sensitive 
subject I think.  Debian will not distribute code that isn't free (as in 
speech) according to the Debian Social Contract and Debian Free Software 
Guidelines.  That means that FastJet as distributed by Debian, does not 
have certain plugins because of the licenses attached to those plugins.  
  So when building Rivet, one cannot assume that certain FastJet plugins 
are available.  The solution of this patch is to explicitly error out 
when these non-free plugins are called.  I had another suggestion some 
time back, which involved creating a FastJet plugin creation abstraction 
layer in Rivet, and the analyses would then use those to instantice the 
plugins needed.  That allowed the discovery of plugins to be moved to a 
core library without affecting the analyses.  In case of Debian, that 
creator would then balk out on non-free plugins.  If you are interested, 
I think I can dig up the code.

- reproducible-builds.patch:  This ensures that one can compare builds 
by removing the timestamp from the Doxygen generated documentation.

- siscone.patch: Explicitly include the siscone libraries from FastJet 
to avoid searching for it runtime.

- yaml-cpp.patch and yaml-cpp-v5-support.patch:  As for 
purge-convenient-tinyxml-lib.patch, Debian prefers to build against 
existing system libraries rather than embedded libraries.  Since the 
libyaml-cpp library on Debian is a newer version than the one 
distributed with Rivet, these patch fixes up support for the newer 
YAML++ interface.

> FYI: You can find the corresponding Arch page under
> https://aur.archlinux.org/packages/rivet/ (the PKGBUILD link takes you
> to the git repo where this is maintained). But there is clearly not as
> much modification in there as in the Debian case.

That's because Debian (and by extension any Debian-based distro, say 
Ubuntu) is very strict when it comes to policies. This I learned when I 
did the Debian packages of ROOT, which, trust me, required a lot more 
than Rivet does :-)

I think the best strategy, if you are interested in distributing Rivet 
via Debian-based distros, is for you to get into contact with the Debian 
developers of that package.  See

   https://packages.debian.org/source/sid/rivet

It seems that the packages are waiting on a HepMC migration, which 
however seems to move forward.

Yours,

-- 
Christian Holm Christensen 
-------------------------------------------------
  Niels Bohr Institute, Blegdamsvej 17, DK-2100 Copenhagen
  http://cern.ch/cholm, +4524618591