Date: Tue, 31 Dec 1996 00:17:14 +0100 (MET) From: sos@FreeBSD.org To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: sos@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, CVS-committers@freefall.freebsd.org, peter@spinner.dialix.com, peter@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-usrbin@freefall.freebsd.org Subject: Re: cvs commit: src/usr.bin/vi Makefile Message-ID: <199612302317.AAA00845@ravenock.cybercity.dk> In-Reply-To: <10780.851985736@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 30, 96 02:42:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Jordan K. Hubbard who wrote: > > What was wrong with the old ways, base & ports ?? I worked pretty > > well, maybe we should have given it a fancier name or something, > > but it was the right idea... > > The right *general* idea, but the number of problems which it leaves > unsolved are numerous. We ran into the most obvious one the minute we > started writing and incorporating perl utilities into the system, and > perl4 slid on in to solve the dependency problem. We will keep having > dependency problems and the ports & packages collection will keep > being a non-solution to them for just as long as we keep it fully > decoupled from the source & binary distribution system. No problem, perl utils etc have no place in the "base" distrib, problem solved, case closed. And most of the perl utils we have could have been written in C or sh just as easily, they NEVER justified bringing in perl. But then perl justified TCL and then..... > I'm not even sure that keeping it decoupled is such a bad idea, but > you can't have it both ways - either the ports and packages collection > remain ideologically and functionally separate, and things like Perl5 > and TCL come into the tree in order to solve our basic tool dependency > issues, or ports and packages becomes part of a more cohesive > load-on-demand system where the line between initially loaded > distributions and packages goes away entirely (same for sources and > "ports") and we stop even worrying about this, since the user will > configure his system in much the same way as the VM system fills the > buffer cache - on demand! :-) Exactly, its a bit more work, but much more usefull, both to the mimimalists and those that wants the kitchen zink > However, the latter is also a lot of work. Ah, thats the bugger :) Actually no as I see it, we are now extending the base system for which (at least I) feels a deep responsibility for keeping in a working sane condition, THAT means more work, and most of it in areas that I dont need, each time a new monster gets in there. If we keep things seperate, its will be easier to distribute responsibility of those subsystems, and if they fall behind, one can just leave them out and thats it. We need to build a dependency system that then can pull in those ports that are needed when you want to install the kitchen zink etc, but that is a one time charge. It seems we have been bitten by the "easy way out" beast again.. Boy does Linus have it easy, he has just a kernel to worry about... and the users worries about the rest ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612302317.AAA00845>