[Rubygems-developers] The next step toward 0.9.0

Hugh Sasse hgs at dmu.ac.uk
Tue Apr 11 05:29:31 EDT 2006

On Mon, 10 Apr 2006, Jim Weirich wrote:

> I've not heard any complaints about the incremental downloading feature, 
> so its time to start thinking about what needs to be done for a 0.9.0 
> release.

Too much going on for me to experiment with that just now...
> So, to get the ball rolling, I'll make a proposal.
> If a gem has a directory named 'data', then at installation time the 
> contents of that directory will be copied into Config::CONFIG['datadir'] 
> (which is configured to be /usr/local/share on my system).

OK, but presumably something below that....  Would one keep gems separate
from non-gems in there?  I.e., have a .../gems/... directory?  One may 
have several versions of a gem installed, which is not possible for
some packages.

> Here's some points to ponder:
> (4) What happened to versioning the data directory?  Well, good 
> question.  The problem is that there isn't a single data dir policy that 
> will work for everybody.  Some projects might need data versions in lock 
> step with the gem version.  Other projects might choose to version the 
> data dir data structures in a separate versioning scheme.

What sort of other versioning policies might there be?
Unless there's a good reason for other policies, I'd tend to want to
stick with one policy.  Less branching in code to support, less
places to look for things.  Also, tying it to the version of the gem
allows more than 1 gem version to be installed, facilitates
uninstall.  In short, I fail to see the need for a separate
versioning scheme.

> (5a) Just a side note that if users want data versioning, they can do it 
>   themselves with:
>      data/mygemname/V2/stuff.data

Which seems like 4 to me, but I'd go for
> (6) What about an uninstall policy?  I am suggesting by default, gems 
> will not remove data from the data directory.  But, I'm willing to 
> entertain an option on the uninstall command that would also uninstall 
> the data.  Comments?

We (by which I mean the machines I manage) need this.  It is usually
a struggle to get people to invest in new hardware ("But we bought you
a fast server only 5 years ago!") so our disks are smaller than we'd
like.  We have a need to uninstall things completely to save the space
we have.  Trying to figure out what we need to keep and what we can
afford to chuck out would be exacerbated by allowing arbitrary versioning
policies for data directories.  

> (7) On a related note, if the data already exists in the shared 
> directory, should an install copy new files on top of that?  I'm 
> thinking yes, but I'm not sure.

Well, if /usr/share is on one filesystem, one could use hard links
within the different version directories.  SHA-256 should be sufficient
to check the files are identical. [??]  For symlinks, keep the original
files in the newest directory, and put the links in the old ones
(cf how data is stored in CVS -- differences take you back not forward).
Then if the old dir is trashed manually we are still OK.

> Ok, that's enough for now.  Feedback welcome.
        Hope that's useful...

More information about the Rubygems-developers mailing list