Date: Sat, 08 Jan 2000 12:27:47 -0500 (EST) From: Will Andrews <andrews@TECHNOLOGIST.COM> To: (Satoshi - Ports Wraith - Asami) <asami@FreeBSD.ORG> Cc: ports@FreeBSD.ORG Subject: Re: multi-level categories Message-ID: <XFMail.000108122747.andrews@TECHNOLOGIST.COM> In-Reply-To: <vqc4scoddtw.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
<scrapping an idea he wrote a few minutes ago.. didn't sound that good...>
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 <andrews@technologist.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000108122747.andrews>