David Burgess wrote
> Alistair Crooks wrote:
> > 
> > 
> > 1. Move md5 and patch-sum info out of the files/ subdir, thereby
> > losing most of the files/ dirs from most packages.
> > 
> > 2.  Move the PLIST and DESCR and other binary package support files
> > out of the pkg/ subdirectories into the package directory, thereby
> > losing the pkg/ subdirs.
> 
> I don't know about this one...  I like having the PLIST and DESCR files
> in their own directory.

In most cases this directory will only hold two files we are
interested namely PLIST and DESCR with the penality of an overhead of
having to create two directories and three CVS database files.
Efficiency = 40%. I wouldn't mind if these files were relocated into
the top level directory of the package. 

> > 3.  Incorporate other information into the area which holds the digest
> > info for distfiles, distpatches and patches.  In particular, I'd like
> > the size of the distfiles and distpatches to be recorded.  This is not
> > really for file integrity reasons (if the digest doesn't do that for
> > you, it's not a very good digest), more for doing things like putting
> > virtual quotas on sizes of distfile that can be downloaded without a
> > warning.  And also for my personal use - I really would like to know
> > how big a distfile is before I even contemplate downloading it over
> > a dialup line.

This is easily done even now... just enter another field to the
current information stored.

> We still need to have a mechanism for handling multi-architecture patch
> files (like the i386 only patches on Apache?)  Segregating the patches
> from the rest of the package is another area where the existing system
> seems very clean to me.  In fact, I really like having pkg and patches
> directories available.  It just seems to make a lot of sense to me.  Of
> course, moving the files in pkg/ down one level won't make me jump off a
> bridge or anything....

No problems, in this case create a directory and set the PATCHDIR
variable accordingly.

> On the download size issue, it would certainly be nice to be able to say
> "No, wait until the world has gone to bed to download the OpenMotif
> file."  In fact, it would be really spiffy to be able to turn that on
> and off in the /etc/mk.conf (FAST_DOWNLOAD= YES).

I can't see any difficulties in implementing this right now.

> > 
> > Now whether the digests go in the pkg Makefile or in a separate
> > distinfo file like FreeBSD are doing are another topic for discussion.
> > 

A user theoretically could set the PATCH_SUM_FILE and DIGEST_FILE
variable and hence can determine where things should go.

> > Personally, I'd prefer all digest, checksum and size and other
> > ancillary information to go into a separate file. I'd like to
> > avoid overloading the pkg Makefile.

Most packages only need a few entries and these may well as be part of
the package Makefile. For larger packages one can set the DIST_FILE
variable to point to a seperate info file

> 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.

> > 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.

> If I recall correctly, it wasn't the number of files that was the
> problem, it was the number of inodes.  Every directory we can eliminate
> or set of files we can consolidate reduces the inode count.  That gives
> us more room to store more stuff.

This definitely was in my mind when I submitted my changes..

> > Having said that, the COMMENT mods did speed up things just a smidgin,
> > so I maybe wrong here.
> 
> If your machine is fast enough, you don't notice :-)

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.



cheerio Berndt
-- 
Name    : Berndt Josef Wulf            | +++ With BSD on Packet Radio +++
E-Mail  : wulf@ping.net.au             |    tfkiss, tnt, dpbox, wampes
ICQ     : 18196098                     |  VK5ABN, Nairne, South Australia 
URL     : http://www.ping.net.au/~wulf | MBOX : vk5abn@vk5abn.#lmr.#sa.au.oc
Sysinfo : DEC AXPpci33+, NetBSD-1.5    | BBS  : vk5abn.#lmr.#sa.aus.oc