Date:        Thu, 5 Oct 2000 16:00:27 +0200 (MET DST)
    From:        Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
    Message-ID:  <Pine.GSO.4.21.0010051559130.24129-100000@rfhpc8320.fh-regensburg.de>

  | Something that we should address soon is to reduce the number of
  | I-nodes.

I'm not sure I agree on that one, but ..

  | Extracting pkgsrc.tgz takes LONG already, and this will get worse.

this one I absolutely agree with.   But I much prefer David Maxwell's
solution - perhaps even more aggressively then he intended.

That is, but default, unpack just the directories for the categories, and
the top level and category Makefiles and leave everything else in a large
archive file (tar most likely).   Then unpack the rest upon demand (as it
is actually needed).   The absolute time needed for the unpack isn't really
the problem, the problem is the elapsed time between when pgksrc.tar.gz 
arrives and when it is reasonably possible to do "make install" in the
directory of the package that you really wanted and fetched pkgsrc.tar.gz
to obtain (just fetching the pkgsrc directories one by one makes life
too difficult when updated dependencies are required).

  | Saves three dirs for each pkg, plus three more CVS dirs => >6000 dirs that

Why are the CVS directories needed (by most of us) anyway?   As I understand
it, their contents aren't useful?  Couldn't they just be excluded from the
tar.gz file altogether?

The only objection I have seen to this scheme was Manuel's ...

    | I don't like that much. It's usefull to be able to fgrep through the
    | Makefiles, or DESCR, or PLISTS.

which is a valid point, but not one that should make a difference.  That is,
nothing is going to prevent (I hope) those who care from unpacking the whole
thing - the aim should just be to allow unpacking to be deferred until it
is really needed (by you, or by the pkg system to build something).

On the other issue that has been of interest to everyone, I don't personally
care whether there are multiple patch files or not, but only two setups
make sense - either there is one patch file that patches everything, or as
we have now, one patch file per file modified.  Anything other than those
two would be an utter mess.

kre