<div>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).</div><br><div>The max path length one sounds odd: what path is too long?</div><br><div>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!</div><br><div>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.</div><br><div>Andy</div><br><div><signature id="initial"><div><table cellpadding="0" cellspacing="0"><tbody><tr><td colspan="2"><div style="padding-bottom:15px"><div><strong>Dr Andy Buckley, Senior Lecturer / Royal Society University Research Fellow</strong></div><div>Particle Physics Experiment Group, University of Glasgow</div></div></td></tr><tr><td style="vertical-align:top"></td><td><div style="font-size:0.9em;white-space:nowrap;border-left:2px solid gray;margin-left:20px;padding-left:20px"><div><div></div><div></div></div></div></td></tr></tbody></table></div></signature></div><div class="gmail_quote_attribution">On Aug 24 2018, at 8:27 am, cholm <cholm@nbi.dk> wrote:</div><blockquote><br><div><div>Hi Frank et al,</div><br><div>Just to give a bit of context: I talked to Andy who's in Copenhagen for</div><div>a rivet Heavy Ion workshop, and asked if you were interested in the</div><div>Debian patches.</div><br><div>On 2018-08-22 18:01, Frank Siegert wrote:</div><blockquote><div>Dear Christian,</div><br><div>thanks, that's very interesting! I'll take a look at the patches,</div><div>which I suppose are mainly distribution-relevant and not</div><div>upstreamable(?), and might use some also in my packaging for Arch</div><div>Linux. But is it correct that this is still at version 1.8.3 or</div><div>2.0.0beta2?</div></blockquote><br><br><div>I think the patches are against 2.0beta2. Sometimes it takes a bit of</div><div>time for Debian to pick up new versions, as stability is an emphasis of</div><div>the Debian project. However, if upstream (rivet project) decides to</div><div>accommodate some of the things that Debian needs, it can make the delay</div><div>shorter. In other words, if you add the "debian" subdirectory to you</div><div>repo and collaborate with the debian developers on the content, then the</div><div>release cycle can probably be shortened.</div><br><div>Here's how I see what the patches does and why they are there</div><br><div>- doc-building.patch: Removes the "test" directory from the sources and</div><div>excludes the "debian" subdirectory from being parsed. The first part is</div><div>probably to not have additional long documentation in the corresponding</div><div>-doc package.</div><br><div>- fix-analysis-plugin-path.patch. As the set-up is upstream, you</div><div>install RivetAnalysis*.so to <prefix>/lib (i.e., /usr/lib). This patch</div><div>puts the plugins into <prefix>/lib/rivet (i.e., /usr/lib/rivet). The</div><div>Debian policy, which adheres to the FSH standard, says that only</div><div>linkable library can be in /usr/lib. Since the plugins are not linkable</div><div>(or intended for linkage), they should go into a package specific</div><div>directory (i.e., /usr/lib/rivet).</div><br><div>- path-max.patch. AFAIK FHS is pretty specific about the maximum path</div><div>length, which is why it is defined here.</div><br><div>- purge-convenient-tinyxml-lib.patch: Debian prefers to build against</div><div>system libraries rather than embedded codes. So at build time there's a</div><div>dependency on tinyxml development packages being installed. At</div><div>(package) install-time, there's an equivalent dependence on the runtime</div><div>tinyxml library package (see also debian/control).</div><br><div>- purge-non-free-fastjet-plugins.patch: OK, this is a bit sensitive</div><div>subject I think. Debian will not distribute code that isn't free (as in</div><div>speech) according to the Debian Social Contract and Debian Free Software</div><div>Guidelines. That means that FastJet as distributed by Debian, does not</div><div>have certain plugins because of the licenses attached to those plugins.</div><div>So when building Rivet, one cannot assume that certain FastJet plugins</div><div>are available. The solution of this patch is to explicitly error out</div><div>when these non-free plugins are called. I had another suggestion some</div><div>time back, which involved creating a FastJet plugin creation abstraction</div><div>layer in Rivet, and the analyses would then use those to instantice the</div><div>plugins needed. That allowed the discovery of plugins to be moved to a</div><div>core library without affecting the analyses. In case of Debian, that</div><div>creator would then balk out on non-free plugins. If you are interested,</div><div>I think I can dig up the code.</div><br><div>- reproducible-builds.patch: This ensures that one can compare builds</div><div>by removing the timestamp from the Doxygen generated documentation.</div><br><div>- siscone.patch: Explicitly include the siscone libraries from FastJet</div><div>to avoid searching for it runtime.</div><br><div>- yaml-cpp.patch and yaml-cpp-v5-support.patch: As for</div><div>purge-convenient-tinyxml-lib.patch, Debian prefers to build against</div><div>existing system libraries rather than embedded libraries. Since the</div><div>libyaml-cpp library on Debian is a newer version than the one</div><div>distributed with Rivet, these patch fixes up support for the newer</div><div>YAML++ interface.</div><br><blockquote><div>FYI: You can find the corresponding Arch page under</div><div>https://aur.archlinux.org/packages/rivet/ (the PKGBUILD link takes you</div><div>to the git repo where this is maintained). But there is clearly not as</div><div>much modification in there as in the Debian case.</div></blockquote><br><div>That's because Debian (and by extension any Debian-based distro, say</div><div>Ubuntu) is very strict when it comes to policies. This I learned when I</div><div>did the Debian packages of ROOT, which, trust me, required a lot more</div><div>than Rivet does :-)</div><br><div>I think the best strategy, if you are interested in distributing Rivet</div><div>via Debian-based distros, is for you to get into contact with the Debian</div><div>developers of that package. See</div><br><div>https://packages.debian.org/source/sid/rivet</div><br><div>It seems that the packages are waiting on a HepMC migration, which</div><div>however seems to move forward.</div><br><div>Yours,</div><br><div>--</div><div>Christian Holm Christensen</div><div>-------------------------------------------------</div><div>Niels Bohr Institute, Blegdamsvej 17, DK-2100 Copenhagen</div><div>http://cern.ch/cholm, +4524618591</div><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></div></blockquote>