Date: Mon, 04 Aug 1997 15:25:15 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: jkh@time.cdrom.com, current@freebsd.org Subject: installation tools Message-ID: <E0wvFdr-0000UX-00@labs.usn.blaze.net.au> In-Reply-To: Your message of "Mon, 04 Aug 1997 12:06:26 %2B0930." <199708040236.MAA17045@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Ok, fair enough. I had assumed that this integration would involve > > make dependancies. I'm not entirely sure how an external tool could > > handle it, but I've enough exposure to know that any solution here > > would involve considerably more "splitting" of the system into more > > components. > > The splitting of the system allows users and installers a degree of > latitude in configuring the system, but it also provides the developers > with more latitude in maintaining and coordinating the software set. Sure, I dispute none of this. OTOH, the "large" bundles in which FreeBSD is currently delivered tends towards a simpler installation, and a more homogenous system (which is one of FreeBSD's primary benefits, imho). I'm not arguing that things should stay the way they are, only mentioning that further partitioning does not come without /some/ cost, somewhere. The benefits would clearly outweigh them. > > In any case, I *still* think this is largely irrelevent to the > > current discussion. In fact, this argument is somewhat of a straw man > > compared with the core issues involved, regardless of how desirable > > it is as an aim in itself. > > The core issues have actually been completely ignored by most of the > respondents. No, we've just been discussing different things. :-) I have no argument at all that FreeBSD needs a better install toolset. I applaud (loudly!) Jordan's obvious moves towards seeing this happen. > The need for better management tools is one, the other > and one which has received even _less_ consideration is the need to > make the ports collection stand _independantly_ of the base system. This latter is *EXACTLY* the problem, and the entire reason for this discussion. The FreeBSD base system is currently engineered with some degree of interference "built-in" for certain packages. Sure, tcl8.0b2/tk8.0b2 can/should be in ports now or tomorrow, if they aren't already (I haven't been following ports commits for the last few days :-)). The problems are the collisions in the base system. These are real problems, not just inconvenience problems. > ie. it should make _minimal_ assumptions about what it's running on/with, > and satisfy any dependancy requirements internally. This would actually > make the maintainers' job _easier_. Yes. > > Incidently, have you seen the Debian Linux installation and package > > tools? While I really hate the ui, the concepts involved are very > > good. I > > Debian is a primitive version of what I _still_ suggest you go and look > at. Please? Do you have an account somewhere I could use? Preferably with enough access so I can run the thing. :) OTOH, I've seen Sun's effort at this, and while the concept is fine, their implementation is terrible (with /opt/... this and /opt/... that and symlinks all over the place making the filesystem looking like a christmas tree). Regards, David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0wvFdr-0000UX-00>