From owner-freebsd-ports Sat Jan 8 9:28: 7 2000 Delivered-To: freebsd-ports@freebsd.org Received: from asgaard.whispering.org (208-241-93-179.hsacorp.net [208.241.93.179]) by hub.freebsd.org (Postfix) with ESMTP id 76FBB15978; Sat, 8 Jan 2000 09:28:00 -0800 (PST) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (23-125.008.popsite.net [209.69.197.125]) by asgaard.whispering.org (8.9.3/8.9.3) with ESMTP id MAA24983; Sat, 8 Jan 2000 12:27:51 -0500 (EST) (envelope-from will@blackdawn.com) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id MAA12402; Sat, 8 Jan 2000 12:27:48 -0500 (EST) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 08 Jan 2000 12:27:47 -0500 (EST) Reply-To: Will Andrews From: Will Andrews To: (Satoshi - Ports Wraith - Asami) Subject: Re: multi-level categories Cc: ports@FreeBSD.ORG Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 08-Jan-00 Satoshi - Ports Wraith - Asami wrote: > 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). Well, basically, I don't like the way we're limited by the filesystem - it makes it slightly difficult to create any given number of levels of subcategories in each main category, without losing consistency. [ Did that make sense? ] > 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). Not only that - but some ports will need to have their names moved to lowercase.. things like ORBacus, Mesa3, ORBit, and others.. > 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 This is the number one problem with the Ports Collection as it is today, IMO. I know a lot of people would be much happier if the copying of the Ports Collection from their -REL CDs would happen a lot faster. But we have thousands (tens of thousands?) of files involved... I just can't bear to imagine how long it'll take once we have 10,000 ports. It certainly seems like a redesign is in order. > 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.) Combine ${SCRIPTDIR} + ${FILESDIR}? ${FILESDIR} seems most generic. > 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: Why wouldn't it be a Good Idea? Can't we just patch using a patch-* regex in ${.CURDIR}? IMO, combining ${FILESDIR} and ${SCRIPTDIR} wouldn't be too bad an idea. It's not like anyone's scripts would break. > 1 CVS/ 1 Makefile 1 PKGCOMMENT > 1 PKGDESCR 6 PKGPLIST 1 md5 > 1 patches/ Hmm.. just had a thought. That CVS directory - I normally rm -rf all of them so that the patches I send via send-pr won't have them in there. But we could drive towards having people use these CVS/ dirs for what they're for - making patches. Seems like porting.html could cover this topic..? > (Hmm, maybe I should call the package files "pkgCOMMENT" etc....) Yeah, that would make more sense. > What do you think? Well, I'm not sure that eradicating ${PKGDIR}, ${FILESDIR}, etc. would help much with management.. or filesystem performance. > 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.... ;) This is a good idea. It would help newbies figure out where to find the checksum by themselves.. BTW, is the current format for files/md5: MD5 (ORBit-0.5.0.tar.gz) = ff977db3e5273bf6e13dd3124bed0696 efficient? Seems like we could program the makesum target to remove the first three tokens altogether. Right now, this is what is used to extract the checksum: CKSUM2=`${GREP} "^MD5 ($$file)" ${MD5_FILE} | ${AWK} '{print $$4}'`; We can simplify this to `${GREP} "^MD5 ($$file)" ${MD5_FILE}`, if `makesum' target were modified to handle this. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message