Date: Mon, 14 Feb 2000 06:27:14 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: asami@FreeBSD.ORG Cc: freebsd-ports@FreeBSD.ORG Subject: Re: /usr/ports/ too big? Message-ID: <0002140753000C.06543@nomad.dataplex.net> In-Reply-To: <vqcln4oi2k2.fsf@silvia.hip.berkeley.edu> References: <20000209215806.M99353@abc.123.org> <00021222301300.02765@nomad.dataplex.net> <vqcln4oi2k2.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Feb 2000, Satoshi - Ports Wraith - Asami wrote: >This is my take of the situation. > > (1) Users who don't have enough disk space to keep the entire > /usr/ports can use packages. (The distfiles and space required to > compile some of the ports are far more than the entire ports tree > anyway -- it doesn't make sense to complain that the ports tree is > too big if you have enough space to compile stuff yourself.) The fact that it takes so much working space is just an argument in favor of selectively reducing the space needed to hold the skeleton of the ports that are not being built at the present moment. Although I haven't checked recently, some ports used to be "source only" because of license restrictions. A machine with limited storage resources still needs a reasonable method to "stay current" and recognize that updates have occurred. Have we given up on "patching" ports? (Is there no point in transferring only a small additional patch and rebuilding from the source that I already have cached?) Fetching a new package for each change is expensive (in terms of network costs) compared to just fetching (or cvsup updating) an additional patch. However, if your team is always "starting over" with a new tarball, there is little point. > There is also the portcheckout script that can be improved to use > cvsup or something to work without a local repository. I could never get it to work. The idea is sound, but ... (not to be taken as a criticism of portcheckout) Personally, I prefer CVSup. Still, I think we need to maintain a SIMPLE interface that "fetch" can use. IMHO, our present handling of distfiles should be extended to handle the selective population of a ports tree. > (2) Users who don't have enough disk space to keep the CVS repository can use cvsup in checkout mode. Granted it doesn't work without a network connection but you can't fetch distfiles without the network either. Understand that I am "thinking ahead". One of my ideas is to turn the FreeBSD kernel and userland into a limited number of packages. Having EVERYTHING in the ports system could greatly simplify system installation because we could eliminate the redundant modes of distribution. - - Boot the pico-installer and start installing "packages" (a kernel, base commands, kde, etc.) The same mechanism can be used throughout. In that context, fetch the new "package" is equivalent to wourkin only from snapshots and clearly inefficient for those who update regularly. > (3) There's always cvsweb for people who are interested in past > versions. I don't know about you, but I am often debugging "offline" and need to look at the recent changes to try to figure out what change might have broken my setup. I then need to selectively revert a few files and press on. Having some of the cvs tree available onboard is a great help. Having the whole tree, with changes back to the birth of Christ (well, BSD4.4) is of NO additional value. On the rare occasion that older history is useful, I will gladly mount the appropriate CD to dig further back. > (4) We recognize that the current organization is suboptimal [...] will fix that soon. Thanks. The journey ... begins with a single step. Every step helps. > It seems to me that your proposed solution only helps a small minority of people for a fairly large cost in implementation and running. Implementation cost is "one time" and I am proposing that I do much of it. I'm not sure what additional costs you see in running it. Once set up, it should run itself. The primary savings are in the distribution system. Lowering the overhead of processing thousands of request each day is a savings that is "hidden" because the end result appears to be the same (although perhaps incrementally slower) But then most "coders" have little appreciation of the administrative costs in supporting their infrastructure. All they see are the successes (and especially the failures). Few office workers ever stop to think about the difficulty or cost in administering the facility. They just EXPECT to have heat, light, power, garbage collection, etc. Then they rebel when ask to separate scrap paper from discarded paper coffee cups. Saving a penny doesn't seem significant to the individual. But saving a penny on each worker every day can have a huge impact on the corporation. And on the other end, tailoring the available products to meet the real needs of the customer will ultimately make or break the company. Right now, it's pretty much all or nothing. The users are treated as either clueless newbees or totally immersed geeks. There is no transition. I know the the FreeBSD'ers CAN do better. However, they are too busy guarding the sandbox. RedHat is stealing potential users every day. Wake up! Every user has a pocket full of sand. -- 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?0002140753000C.06543>