Date: Sat, 20 Mar 2004 07:14:51 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: freebsd-current@freebsd.org Subject: Re: Pkg-based base system. Message-ID: <20040319201450.GN56509@cirb503493.alcatel.com.au> In-Reply-To: <20040317110938.GA86023@dragon.nuxi.com> References: <20040315134745.1eb201f4.manlix@demonized.net> <20040315125121.GC91150@abc.123.org> <20040315135725.3cc70f97.manlix@demonized.net> <20040317110938.GA86023@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319201450.GN56509>