Date: Fri, 02 Aug 2002 11:07:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Zak Johnson <zakj-freebsd-arch@nox.cx> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: OpenSSL vs. -lmd Message-ID: <3D4ACA59.298777B@mindspring.com> References: <200207311641.g6VGfRWj099655@freefall.freebsd.org> <20020801143059.GA536@nevermind.kiev.ua> <200208011151.55478.mi%2Bmx@aldan.algebra.com> <3D498FB4.6987B696@mindspring.com> <20020801195640.GQ26797@madman.nectar.cc> <3D4998F9.A736EA85@mindspring.com> <3D499CF3.4030601@ntlworld.com> <3D49A37B.BA3C2982@mindspring.com> <20020801212004.GC6856@opiate.nox.cx> <3D49AF37.C7E1E272@mindspring.com> <20020802154452.GA25577@opiate.nox.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Zak Johnson wrote: > On Thu, Aug 01, 2002 at 02:59:19PM -0700, Terry Lambert wrote: > > I think the idea of fundamentally breaking the system into > > optional and highly granular components has a large amount > > of "grass roots" support; discussions like the packaging > > discussion would not attract nearly so much participation, > > were that not the case. > > What is preventing a change in this direction from happening inside > FreeBSD (as opposed to a new distribution)? Is there a large set of > committers who feel that making FreeBSD more/completely modular is a bad > idea? Or is everyone just waiting for libh? This is a good question. I think the answer is that this is one of the cases where it is not possible to get from poin A to point B via evolution instead of revolution. I've tried to tackle this problem locally, but every time I've tried to get a handle on it, it's come down to the need to have "make installworld" result in a system that would have resulted from the installation of a pagake set that represents the default install, as a minimum solution set for the problem. In the case of the "installworld" target, however, the real solution set is a maximal, not a default, install, because the problem is trying to get a solution set from which any potential default install can be derived. To keep the previous ability with the "NO_THIS" and "NO_THAT" (particularly the ability to build *without* certain components, like documentation, where the source code for the tools is not part of the FreeBSD source tree itself, and requires ports), it basically means that such a system has to be able to take its own partial input as output. The documentation build itself is non-orthogonal. The ports that are part of the system end up having to to be imported into the source tree (certain FreeBSD versions are in fact not buildable from source these days, for lack of archived copies of old instances of the tools for the documentation system and the ISO images). The only clean way I've been able to come up with is the one I keep coming back to, which is to (effectively) start with the goal in mind, and completely reengineer the build system to support it. In practice, this means being able to recover all package data, including package metadata, from an installed system, in order to recreate the install images that would recreate the installed system, plus additional tools to get over the bootstrap barrier (normally, tools which are optionally installed, or available only on the CDROM). If this is what we have to have on hand as a result of a "make world; make installworld", then it means some fundamental changes for the "installworld" target, and probably the "world" target. If we extend this, and say we want to be able to "pack up" a PicoBSD distribution (for example) from the installed image, so that we can build a distribution image that results in a flash image... well, then the scope of the problem becomes more clear. If we extend it to arbitrary reconfiguration of the kernel (as would be the case in an embedded systems shop that wanted (1) build environments for its engineers and (2) a image distribution for the embedded system itself and (3) a binary image of an installed embedded system for support of a chroot "build envornoment" for the embedded system for use by the engineers (or even just a cross-version of FreeBSD), well then the full scope of the problem becomes apparent. I think it's really unlikely that that level of backward compatability loss would be acceptable to the project, particularly if it were to take place in the context of a 4.x branch system... which would have the effect of forcing a 5.x back-integration. If someone can think of an alternate approach which is capable of solving the problems, without being so alien as to not be possbile inside the context of the project itself, I'm all ears. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4ACA59.298777B>