Date: Mon, 14 Feb 2000 00:26:31 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: "David O'Brien" <obrien@FreeBSD.ORG> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: /usr/ports/ too big? Message-ID: <0002140546250A.06543@nomad.dataplex.net> In-Reply-To: <20000213201417.C17462@dragon.nuxi.com> References: <20000209215806.M99353@abc.123.org> <00021319283201.06543@nomad.dataplex.net> <20000213201417.C17462@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Feb 2000, David O'Brien wrote: > Ah... and just *how* is your suggestion going to affect that? We have > already agreed that a cvsup of the /usr/ports (not the CVS ,v files) is > the minimal amount of space we can get Ports down to. No. The minimum is the INDEX and a few support files and something like portcheckout. [I think "make" and "fetch" would work adequately with a small makefile to guide them] I think that a better alternative would be the set of DESCR files or some similar short abstracts. I n order to KISS expansion from there, I would advocate that we have a repository of 3000+ sharballs, one per port, that could be fetched and expanded into the build tree for their port. I would generate these archives from a script in the CVSROOT of the master repository of the ports. The execution of this script would be triggered by the checkin of a change. Rather than distributing the ports tree, it is sufficient to distribute the 3000+ archives which will reconstruct it. I think that we could simplify some of the dependancy problems if we would place ALL the port build directories (the unpacked archive that we fetched) in a single directory. As long as we are following a single dependancy chain, and clean up afterward, there would not be too many entries in that directory. However, if we need to support the complete checkout of all ports AT THE SAME TIME, we need to stick with the present two-level scheme. There are numerous refinements that we can easily add. For example, if we fetch only those sharballs for "ports of interest", it becomes easy to update that reduced set with cvsup. The user benefits because his working set of ports is smaller and can be updated faster. The distribution servers benefit because they have significantly fewer objects to handle. This should translate into decreased time and effort to serve their clients. The port maintainers are not significantly affected. Once the initial changes are made to transition to the altered structure, it is pretty much "business as usual" -- Richard Wackerbarth rkw@Dataplex.NET 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?0002140546250A.06543>