[Rivet] Debian Rivet package w/patches

[Andy Buckley]

Interesting about the rule on installation of non-linkable plugin libraries into .../lib/rivet. That sounds like a good idea, and one that we could easily build into our default path searching. But it's a major behavioural change, so let's queue that for 3.0.0 (i.e. soon... just in time, in fact).

The max path length one sounds odd: what path is too long?
Re. yaml-cpp and TinyXML: the latter is gone, and the former is in need of an upgrade to v0.6. We didn't use yaml-cpp 0.5 since it required Boost at the point we got rid of it. I guess we could try to build in a "use system copy if available" behaviour... but we specifically mangle the namespace to avoid clashes, so there could be compatibility issues. I think our behaviour is really ok for "embeddable" libraries like these: the ~whole point is that they are tiny!
Generally, system packaging isn't a priority for us... I don't buy the "Debian is very stable" line as an explanation for why their copy is more than 5 years old, so it more illustrates that these packages tend to get made by people who lose enthusiasm after a couple of iterations and then the defunct copy is worse than none. Frank is the honourable exception there ;-) But we should try to follow the rules and make packagers' lives easier whenever easily possible.
Andy
Dr Andy Buckley, Senior Lecturer / Royal Society University Research Fellow
Particle Physics Experiment Group, University of Glasgow

On Aug 24 2018, at 8:27 am, cholm <cholm at nbi.dk> wrote:
>
> 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
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20180827/0fa05de9/attachment.html>