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>