[Rivet] auxiliary scripts in several generators.

[Pere Mato Vila]

Hi David,

  I understand that nothing will be done. So I will not insist but you are in my opinion wrong.  The fact is that many packages (more than 100) are being re-installed at various locations (shared files systems, CVMFS, etc.) in particular  for the LHC Grid,  making these "config'" scripts useless.  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 (see http://www.gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html#Supporting-Relocation).
  Cheers,

			Pere
 

On Apr 8, 2013, at 6:01 PM, David Grellscheid <david.grellscheid at durham.ac.uk>
 wrote:

> Hi Pere,
> 
> If I understand correctly, you're trying to use/develop yet another
> reinvention of a packaging system. No mature packaging system
> I know needs the software they package up to change, especially when
> that software behaves as expected compared to other GNU-style projects.
> I think the config scripts taking their information from configure runs
> are fine.
> 
>>>> installations into kits which are distributed on Grid sites
>>> 
>>> Yes, but surely that "kit" has a known path structure. This is what
>>> needs to go into configure. AFS only appears as a temporary 
>>> location in DESTDIR.
>> 
>> The problem is the plural with 'sites'. In general each site will 
>> have a different place.
> 
> In that case, how does the kit know where to put things?
> 
>> Honestly, you do not think that having an installation relocatable is
>> better? 
> 
> This isn't the discussion point. I also think it's better if it would
> rain less in the UK, but it is not something that can be achieved. The
> relocatability you envision is impossible to get in all generality with
> GNU-style shared-library Linux systems. You'd have to go down the OS X
> route of including all dependencies in each app bundle, and just live
> with the multiple copies of common libraries. And even within those app
> bundles the paths are known, not arbitrary.
> 
> Herwig++ needs to know where various of its internals are in relation to
> each other. We can ensure that automatically at configure time, as long
> as we're told the final layout. If then the user moves the components
> all over the place, it becomes the user's responsibility to tell the
> binary where to find everything else (via explicit). From within Herwig
> we're not going to go searching for the location all the bits.
> 
>> Perhaps the solution I proposed is not good enough but I am
>> sure a solution can be worked out to cover all cases.
> 
> All I'm pleading for (in too many words, sorry!) is to solve a packaging
> problem at the packaging level; the codes, including the config scripts
> are fine as they are by default.
> 
>  David



-------------------------------------------------------------
Pere Mato  CERN, PH Department, CH 1211 Geneva 23, Switzerland
          e-mail: pere.mato at cern.ch      tel: +41 22 76 78696
          fax:  +41 22 76 68792            gsm: +41 76 48 70855