From owner-freebsd-current@FreeBSD.ORG Fri Mar 19 12:15:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55ECF16A4CE for ; Fri, 19 Mar 2004 12:15:00 -0800 (PST) Received: from mail019.syd.optusnet.com.au (mail019.syd.optusnet.com.au [211.29.132.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45F5143D1F for ; Fri, 19 Mar 2004 12:14:59 -0800 (PST) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i2JKEvB04656 for ; Sat, 20 Mar 2004 07:14:57 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i2JKEpSU033148 for ; Sat, 20 Mar 2004 07:14:56 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id i2JKEp0j033147 for freebsd-current@freebsd.org; Sat, 20 Mar 2004 07:14:51 +1100 (EST) (envelope-from jeremyp) Date: Sat, 20 Mar 2004 07:14:51 +1100 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20040319201450.GN56509@cirb503493.alcatel.com.au> References: <20040315134745.1eb201f4.manlix@demonized.net> <20040315125121.GC91150@abc.123.org> <20040315135725.3cc70f97.manlix@demonized.net> <20040317110938.GA86023@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040317110938.GA86023@dragon.nuxi.com> User-Agent: Mutt/1.4.2i Subject: Re: Pkg-based base system. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 20:15:00 -0000 On Wed, Mar 17, 2004 at 03:09:38AM -0800, David O'Brien wrote: >3. Sounds like you want Linux with its RPM's, not BSD. Or Solaris or Tru64 or ... All of which has a very small core system and things like MUAs, MTAs, editors etc are all optional bits. > We consciously > don't wrap the base system in pkg_add tarballs. We generally LIKE the > entire system being a single integrated blob. Like MS Windows :-). Some people like having a single FreeBSD base system blob. Other people would like to have what is now the base system broken down into a much smaller core and lots of optional bits - because they want to save space (eg in an embedded environment), remove unwanted functionality (eg in a secure environment) or use alternate tools (eg bind, lp or sendmail replacements). This is mostly possible now IF you build your system from source - there are various NO_foo knobs (though there could usefully be a lot more) as well as the PicoBSD and NanoBSD toolkits. (I have a highly customised Makefile.inc1 to allow me to build a FreeBSD variant to suit my needs). Someone who does not want to build their system from source doesn't have a choice - all the binaries are supplied as a single blob. If they want to remove bits, they need to understand the system layout and dependencies well enough to manually delete all the (ir)relevant files. There is no reason why the optional bits of what is now the base system need to be less well integrated than they are now - sysinstall already has binaries, sources, documentation etc split up. It would be possible to further split these lumps as well as record content and dependency information to allow clean de-installation. Given a set of "pkg-plist" files and relevant dependency information, there's no reason why a "make release" couldn't turn the buildworld results into a collection of packages that the existing package management infrastructure could manage. To date, no-one has invested the effort necessary for this (or any alternative mechanism) - at least publicly. Committers/developers already build from source and so being able to control the installation of a binary package is not a high priority issue for them. End users don't (at least initially) have the skills or expertise to create the package list files necessary to split up the base system - and by the time they do, they know how to build from sources and are no longer as interested in expending the effort. In any case, it couldn't be implemented in FreeBSD without the buy-in from at least one committer and general agreement not to veto the end result - and the general tone of this bikeshed is not encouraging. In my case, I could probably usefully use an installation system that provided much finer control over what was installed. But I have a work-around that mostly meets my needs and lots of other things on my todo list so I doubt I will ever get around to investing the effort to develop it. Peter