From owner-freebsd-ports Sat Jan 8 3: 6:10 2000 Delivered-To: freebsd-ports@freebsd.org Received: from m0.cs.berkeley.edu (m0.CS.Berkeley.EDU [128.32.45.176]) by hub.freebsd.org (Postfix) with ESMTP id DE09314EDA for ; Sat, 8 Jan 2000 03:06:06 -0800 (PST) (envelope-from asami@stampede.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca7-252.ix.netcom.com [209.109.235.252]) by m0.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id DAA15269; Sat, 8 Jan 2000 03:05:43 -0800 (PST) (envelope-from asami@stampede.cs.berkeley.edu) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id DAA61532; Sat, 8 Jan 2000 03:04:52 -0800 (PST) To: Will Andrews Cc: ports@FreeBSD.ORG Subject: Re: multi-level categories References: From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: 08 Jan 2000 03:04:27 -0800 In-Reply-To: Will Andrews's message of "Mon, 03 Jan 2000 16:14:38 -0500 (EST)" Message-ID: Lines: 127 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm. Still only one response? Is anyone awake? Hello earth! * From: Will Andrews * > 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