Re: missing info in the models tarballs.

(Cc'ed to the list)

On 3/6/07, Svenn Are Bjerkem <[email protected]> wrote:
> On 3/5/07, a r <[email protected]> wrote:
> > I don't mind compiling models as long as it works in every situation.
> > And there are only two ways of achieving this: preparing packets for
> > each (Linux) distribution version&architecture, or shipping a bundle
> > of gnucap, gcc and other devel tools. I don't want to see queue daemon
> > halting my tasks only because it decided to run them on a host with
> > gcc installed in another directory.
>
> Isn't this going to be an overkill package? I would hate to see gcc
> recompile everytime I upgrade gnucap on Gentoo. Maybe I am missing
> something here, but wouldn't it be better to have some kind of
> cross-reference file with lots of "if running on {machine} then find
> gcc in {directory}" that gnucap will use if you give her the right
> option. If you are running on a grid, then you have a lot of overhead
> anyway, and this would prevent installing loads of instances of gcc.
> My experience from grids is that the sys-ops hate to have too many
> different systems and standardize on hardware that either run SLES or
> RHEL. But again, I may be missing something.

It certainly does not make sense to ship all required source code. If
someone wants to compile gnucap, working out all the dependencies will
not add much hassle. What is the problem, though, is work environment
maintenance burden. Discrepancies may occur between machines,
architectures, user settings, versions, compile-time settings etc. You
cannot handle it without elaborate (and fragile) configuration scripts
which add to complexity and run-time cost. A relocatable binary blob
is not pretty but solves many problems.

Obviously this is not needed for well defined environments (fresh
installation of a particular distribution version or a livecd).

\R.