On Sat, Apr 14, 2001 at 09:03:08AM +0930, Berndt Josef Wulf wrote:
> > I've been noodling on this all afternoon, and it might just be a good
> > idea.  Putting this stuff into the Makefile wasn't a bad idea - but
> > having a new file (especially one that we control the format of) could
> > be an easier solution.  It would reduce the inode count and get rid of
> > at least one directory, which I think is a Good Thing (tm).  We could
> > even extend the file to include the pkg/ file contents (if that turns
> > out to be a good idea).
> 
> Just place a comment character in front of the line and you're free to
> use any format you desire.

The issue isn't what can be done, it's how it should be done.

And I'm wary of just dumping everything into one file, even if it's
totally unrelated, simply because of the deficiencies of the source
code control system in use, or the time taken to extract informatino
from a tar archive.
 
> > > Also, I believe that the number of files isn't necessarily the kicker.
> > > I think it also has a lot more to do with the proliferation of
> > > directories in pkgsrc, both when extracting from a tarfile, and when
> > > updating using cvs, due to synchronous writes of dirs, and cvs having
> > > to maintain separate CVS dirs for every directory it supports.
> 
> I don't know about this. I can tell you that it takes 10min + for my
> system to settle after an update on the entire pkgsrc system with the
> harddisk going flat out. Well, this definitely would reduce the time
> it takes to update the CVS files for 2000+ packages.

As far as I understand it, cvs is pruning directories, and calculating
timestamps for all the files it has checked out. By reducing the number
of directories (files/ in most cases), you are cutting out a major part
of the work that is done.
 
> I still believe that the submitted patch would speed things up and
> would cause much of a problem to implement. Said that, I don't have
> the resources to proof this in hard facts. Perhaps on of the bulk
> builders could to a run in comparison?
> 
> So, how about we come up with requirement specifications and see to it
> then? Let's built something more efficient than what we currently have.

We shall be implementing the diffs I posted previously to this list (and
to other interested parties) RSN. It will be more efficient than what we
currently have.

Regards,
Alistair