From owner-freebsd-arch Sat Feb 17 11:47:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 7AF2737B4EC for ; Sat, 17 Feb 2001 11:47:21 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1HJkbH06909; Sat, 17 Feb 2001 11:46:37 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Kris Kennaway Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Kris Kennaway of "Sat, 17 Feb 2001 03:21:58 PST." <20010217032158.A85153@mollari.cthul.hu> Date: Sat, 17 Feb 2001 11:46:37 -0800 Message-ID: <6905.982439197@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, currently the installer does impose policy by virtue of the > source components being in one menu and the ports in another, with > all of the "src-like" bits like 44bsd-more, 44bsd-csh, etc, jumbled in > amongst the crap like GNOME and four million versions of breakout. So Again, this isn't the installer at work. Those components are *already* broken out into separate pieces and all the installer does is reflect the existing status quo. Sure, I could have tried to paper over the differences by having the installer invoke the appropriate installation magic behind the users back and create the illusion of a unified front, but we're talking about a lot of work to maintain an illusion which only collapses the minute the user starts thinking about updating those components anyway. > That might be one way to go, but it's clear to me that any change > needs to become manifest in sysinstall, being the interface to > installing the various bits of software, and the rest will attend to > itself. I really think you're conceptualizing this backwards. :) > The most obvious way to handle this (not requiring any fancy XML ports > tree rearchitecturing) would be to just rip out the sysinstall code > which treats distributions separately and rewrite it to use packages. Perhaps obvious, but not correct. The reason sysinstall hasn't used packages for the base system all along is due to the temporary space requirements of packages. The extraction technique used by pkg_add was always aimed at small stuff (a bad design I've already described and lambasted more than once in this forum) and there's just not enough room to have "base" transit through /tmp or even /usr/tmp first. Go UTSL for pkg_add if you don't believe me. :) > There is nothing preventing us from installing the base system as > packages right now, except that sysinstall demands those bits to be > distributions. I wish that were true. :( However, even that would only be a stop-gap measure since we're still looking for something which incorporates sources, binary packages and "distributions" into one unified design here. What you and Marc are proposing doesn't represent the true goal, it's just another step along the "hack it some more" path and I'd like to get off that one now. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message