[Rivet] auxiliary scripts in several generators.

[David Grellscheid]

Hi Pere,

> I understand that nothing will be done.

In Herwig++ that is. I can't decide by myself for the others.

> So I will not insist but you are in my opinion wrong.

Don't misunderstand me. I'd like to be convinced, but I really cannot
see at the moment how it can be done in Herwig. And dumping the design
flaws of the grid lower and lower down the chain until you stop at the
original authors of various tools is not an efficient way to solve the
problem. If Genser comes up with a neat way of how we can work around 
this Genser-created reloc problem centrally, I'd be happy to look at it 
for Herwig++.

> The fact is that many packages (more than 100) are being re-installed
> at various locations (shared files systems, CVMFS, etc.)

Re-installing always works anyway. It's only the raw copying of binaries
that's problematic. Also, don't both your examples have a fixed path
structure, so the DESTDIR approach works perfectly fine?

> making these "config'" scripts useless.

I fully agree, *-config scripts are useless other than for fairly
mainstream end users, who need to link one or two self-written things to
some library. I would actually say that ./configure setups that rely on
*-config scripts for their checks are broken, and the discussion we've
had shows why. To ease relocation, all other lookup aspects can be
controlled with environment variables (PATH, LD_LIBRARY_PATH,
PYTHONPATH, MANPATH), but typically *-config scripts ignore these values
completely.

> Aiming for relocatable packages is not violating any GNU-style
> commandment and it can be done. Indeed the GNU community is providing
> a module to support relocation

Sure. There's also Binreloc. It works fine if all you have is binary
executables and libs with hardcoded paths that need rewriting, but not
easily with *-config scripts or packages like Hw++ with its own separate
tree of generator supplementary files and their cross-relations.

As far as I see, the most straightforward solution is still a small 
number of separate builds/installations for 1) AFS, 2) CVMFS, (which 
covers all the Grid issues right there) and 3)..n) the shared file 
systems you mentioned. Rather than copying the final result over, why 
not make the build process portable, so deploying on a new shared FS is 
a button push.

   David