Re: Gems and repackaging, hopefully helpful

On Sat, 1 Oct 2005, Jim Weirich wrote:
> Actually, RubyGems is entirely silent on the matter of data storage.  Thus
> the problem of individual authors doing the relative file path thing.
>
> If RubyGems provided a option to copy files in to a area designed by
> Config::CONFIG['datadir'], would that be adequate?

Excuse me jumping in on this point: I think there are a few things
we need of this type:
   A space for data that is Read Only
      (You can say how big it will be before you write it, possibly
      when you unpack the gem. "The steady state of disks is 99%
      full" and all that. Always good to know.)
   A space for data that is likely to change, like in /var/...
   A space for Architectural-dependent data.
       Is that always read-only?  If not we'd need to split that.

These are possibly on top of the usual spaces to stick the "normal"
libraries and executables.

I don't know if the variable data is ever shareable (Locking under
NFS is, at least, tricky) but there may be a need to split these
into information that is site- (Eg, laboratory-) wide, and
information that is host specific.  For example, some machines
sharing an architecture may behave differently if one is a server
and the other isn't.   The frustrating thing about mounting
/usr/local is that some software treats it as local to the lab and
other software treats it as local to the machine, in my experience.

Six (eight?) areas to reference is rather a lot, but I don't see a way to
cover all bases without this orthogonality.

Is anyone being hit by better bolts of inspiration than me? I really
hope so.
>
         Hugh