Skip site navigation (1)Skip section navigation (2)
Date:      08 Jan 2000 03:04:27 -0800
From:      asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami)
To:        Will Andrews <andrews@TECHNOLOGIST.COM>
Cc:        ports@FreeBSD.ORG
Subject:   Re: multi-level categories
Message-ID:  <vqc4scoddtw.fsf@silvia.hip.berkeley.edu>
In-Reply-To: Will Andrews's message of "Mon, 03 Jan 2000 16:14:38 -0500 (EST)"
References:  <XFMail.000103161438.andrews@TECHNOLOGIST.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
Hmm.  Still only one response?  Is anyone awake?  Hello earth!

 * From: Will Andrews <andrews@TECHNOLOGIST.COM>

 * > The problem with this approach is that we'll have to move a lot of
 * > stuff every time we decide to split up a category, since we can't just
 * > create a new subcategory and only move stuff that fits into there --
 * > everything has to moved to "some" subdirectory.  This will cause a lot
 * > of "misc" directories in the ports tree, and also make ongoing
 * > category maintenance a very painful (I think).
 * 
 * Yeah. I'm not sure that this whole directory structure is that intuitive. It
 * seems natural, but it comes with many inflexibilities, like the inability to
 * split up into sub-[-sub[-sub[-sub]]]categories.. you get the idea.

I'm not sure what you mean here.  The categories can be arbitrarily
deep.  It's just that a node can only have internal nodes (other
subcategories) or leaves (individual ports) as children, not both.
It's not as restrictive as to, say, a requirement that the entire
ports tree has to be N level deep (where N is some fixed number where
all the individual ports will be found -- what we have now is N=2).

 * > Another solution is to add another rule on naming of categories and
 * > individual port names.  For instance, if we decide to make all
 * > categories start with uppercase and all ports with lowercase, the user
 * > will see "Jokes" and "Shooting" right at the beginning of the
 * > directory listing (assuming they aren't using some brain-damaged
 * > software which can only sort case-insensitively).  This will be much
 * > easier on the normal transition as we can move things piecemeal,
 * > except that everything will have to be moved mechanically to the
 * > uppercase categories as the first pass.
 * 
 * Ooh! I like this idea! Distinguishing in this manner seems like a real
 * solution. I'm speaking mostly from a cosmetic point of view. I really wouldn't
 * know how hard or easy this would be, though..

Well, it has a certain nice side effect that we can immediately tell
which ones have been "converted" and which have not been, since the
converted ones start with uppercase.  Of course one drawback is that
the entire ports tree has to be repo-copied, but you also have to
repo-copy almost the entire tree with the other approach anyway (the
only categories that don't have to be split will be the ones that are
small enough and also aren't moved under another subdirectory, so only
a small number of ports won't be moved, unless we have a large number
of small categories, which we don't).

One other thing to consider is that, since we're moving the entire
tree anyway, we can try to streamline it a bit.  For instance, it is
quite well known that cvs (and even the filesystem itself) is not very
efficient in handling the thousands of small directories with small
files.  We can try to get rid of some of the subdirectories as we move
along.  For instance, we can get rid of ${PKGDIR}, move md5 from
${FILESDIR} to the top, and even move the patches up one level.  (I
think ${SCRIPTDIR} should stay where it is -- the names in there will
sort quite randomly, and not many ports have it anyway.)

Something like this:

editors/emacs/Makefile
          .../files/emacs.sh
          .../files/md5
          .../patches/patch-aa
          .../patches/patch-ab
          .../patches/patch-ac
          .../patches/patch-ad
          .../pkg/COMMENT
          .../pkg/DESCR
          .../pkg/PLIST
          .../pkg/REQ
          .../scripts/pre-configure

to

editors/emacs/Makefile
          .../PKGCOMMENT
          .../PKGDESCR
          .../PKGPLIST
          .../PKGREQ
          .../files/emacs.sh
          .../md5
          .../patch-aa
          .../patch-ab
          .../patch-ac
          .../patch-ad
          .../scripts/pre-configure

It may not be a good idea to remove the patch directory, even though
files in there have well-known names -- there are some ports with
dozens of patches.  If we don't move patches, we'll have something
like this:

editors/emacs/Makefile
          .../PKGCOMMENT
          .../PKGDESCR
          .../PKGPLIST
          .../PKGREQ
          .../files/emacs.sh
          .../md5
          .../patches/patch-aa
          .../patches/patch-ab
          .../patches/patch-ac
          .../patches/patch-ad
          .../scripts/pre-configure

Note that for most ports, this will mean ${FILESDIR} and ${PKGDIR}
will entirely dissapear since md5 is the only one in ${FILESDIR}.
This will be what you'll be getting with an "ls" with a typical port:

 1 CVS/             1 Makefile       1 PKGCOMMENT
 1 PKGDESCR         6 PKGPLIST       1 md5
 1 patches/

As opposed to what we have now:

 1 CVS/             1 Makefile       1 files/
 1 patches/         1 pkg/

(Hmm, maybe I should call the package files "pkgCOMMENT" etc....)

What do you think?

-PW

P.S. I'd also like to change the file "md5" to "checksum", (especially
     since we're thinking of putting file sizes and stuff in there),
     but there is always a danger of getting "`checksum' is up to
     date" message.... ;)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?vqc4scoddtw.fsf>