At 09:58 PM 2/9/00 +0100, Kai Voigt wrote:
>Hello,
>
>I'm just doing a cvsup update of my system and -as many times before- I
>realize that /usr/ports/ takes a lot of time and also disk space to sync.
>
># du -sk /usr/ports
>71118 /usr/ports
Is that just source or with some distfiles and <port>/work dirs? Seems a
bit high. By far most of the space is taken up with distfiles once you
populate a system. The number of directories is the killer, which slows
down installing the collection.
>Am I the only one being little annoyed by this fact? Would it make
>any sense to offer some "castrated" ports repository. Like putting
>a target "overview" into each /usr/ports/*/Makefile to list all available
>subdiretories. Then, with some other command, one could fetch the
>current port's directory from the cvs server to install the port.
>
>Do these thoughts make any sense?
A bit. Not certain what you are suggesting here, but something having only
Makefile, DESCR and possibly README.html files for the port. Upon the
first 'make' the rest of the port's directory would be first fetched with
business as usual after that.
My opinion is that from the start when someone installs a system they
should not have to install the entire directory structure. Compared to a
full source install (no X) it takes much too long. And will only increase.
Breaking up ports.tgz has been suggested before. Speeding up the install
should keep the impatient newcomer around and will most likely be
installing the ports collection.
Then there is problem of CVSup. If someone were to install the entire tree
as above and use "ports-all" in their supfile...
More practical to break ports.tar into their respective categories. One
the "base" and other choosen categories are installed.
Having the choice from the start, IMO, would mean less users with the
entire, mostly unused (and certainly not needed!), tree who would later
CVSup everything when updating.
Then add a clear mention of of updating the ports that explains using
"refuse" files along with a handy script that would use
sup/<whatever>/refuse file for further pruning. Then if you keep the
refuse files they could be used to clean fresh installs either by
installing and then deleting or by removing them from ports.tar from the
start, which is what I've been doing for a while.
<sigh> There is the ever present problem of getting users to actually read
documention, but at least an effort would be made.
Only just recently trimmed down what I pull from ports. Did so a while
back with doc and www, but didn't take the time for anything further until
recently. Guess the size of the tree and CVSup logs didn't really register
until a few days back (rather ironic) when I pulled for the first time in a
while. Figured then it was time to make things a bit more neat and clean.
Now only need to watch for checkouts and possibly add to the refuse files,
which still need cleaning. The best example being ports/games, which I
only need those that are called for when KDE is installed.
Might want others at some time, but can check out either DESCR or
README.html for candidates. Hmmm... there could be a port of these files
that would compliment the INDEX.
As for the initial install, taking time to trim down the original tarball
saves time. (At least the CVS subdirs are gone.) Yeah, one can also use
NFS and copy the tree, but I prefer to start fresh from a release and
re-CVSup to -stable (or -current), so it's something I every few months.
56279040 ports-3_4.tar
48312320 ports.tar-nolang (only English spoken here :)
44206080 ports.tar-no_lang-no_README.html
39229440 ports.tar (dropped more categories)
34048000 ports.tar (nukes most games)
Getting there. Glad to take some time and work out some more trimming,
since 4.0-RC (2/8 snap) is on it's way over and it will be installed fresh
makeing 'tar --delete -f ports.tar <long_list>' my friend.
Trying to figure out where the time went. Last ran -current prior to 3.0.
8-)
'Nuff ramble.
Jeff Mountin - [EMAIL PROTECTED]
Systems/Network Administrator
FreeBSD - the power to serve
'86 Yamaha MaxiumX (not FBSD powered)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
