Date: Fri, 2 Aug 2002 11:23:11 -0700 From: Jordan K Hubbard <jkh@queasyweasel.com> To: Zak Johnson <zakj-freebsd-arch@nox.cx> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: OpenSSL vs. -lmd Message-ID: <E6F026CE-A644-11D6-B7BD-0003938C7B7E@queasyweasel.com> In-Reply-To: <20020802154452.GA25577@opiate.nox.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-8-613267768 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Lest anyone misinterpret the goals of libh, let me just point out that all libh does is provide a new UI, installation and packaging framework for doing this kind of thing with. It doesn't actually make FreeBSD inherently more modular or help with the changes necessary to the build system to make that happen. I also don't usually agree with Terry's diatribes, but I have to say that he hit the nail pretty much on the head when he said: No, the largest barrier is that *everything* is not a package, so that *anyone* can make a decision on what "unnecessary" means to them, without shooting anyone else in the foot. In other words, if you are trying to define "unnecessary", then you are addressing a symptom, rather than the problem. The "make installworld" target defines what is and is not in "The Base System". For better or worse, this is an Ultimate Truth. Without tackling the problem at that level, it's unlikely that it will ever be solvable. That truly is the more fundamental problem here and something which can be addressed independently of libh, even if the initial target is to simply create a series of FreeBSD packages for each subcomponent and then one or more meta-packages which define the "base" and simply contain a list of dependencies. With the ``extract-in-place'' directive I added to pkg_add(1) some time back, it's even possible to have these packages pretty much do the right thing without having to go through /tmp, it would just require a little smarts in sysinstall to detect them and avoid extracting them in the same fashion as the other packages. Since there never has been a "packaged distribution" of FreeBSD available, that's simply never been worth doing. I personally would smile on any effort to deconstruct src/release/Makefile with any eye towards packaging the bits entirely differently. The packaging strategems currently employed there are based around the 1.2MB *floppy* for godssakes, and if ever there were a bit of legacy baggage worth looking into, it's that stuff. FreeBSD is rapidly growing past its original and humble goals of being a good x86-only operating system and looking at a whole bunch of new technologies (KSE, SMP, fair-share scheduling, etc), all of which is essentially growth along a single technical axis, and it's simply regrettable that its growth in terms of release engineering technology has essentially stagnated around work done in the early-to-mid 90's. Growth along multiple axis can easily occur without being mutually conflicting, so who's gonna step up to the plate? Don't look at me, I did so much of the first system that I always come down with second-system-syndrome when I try to get involved in such things. :-) - Jordan On Friday, August 2, 2002, at 08:44 AM, Zak Johnson wrote: > 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? > > -Zak > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-8-613267768 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Lest anyone misinterpret the goals of libh, let me just point out that all libh does is provide a new UI, installation and packaging framework for doing this kind of thing with. It doesn't actually make FreeBSD inherently more modular or help with the changes necessary to the build system to make that happen. I also don't usually agree with Terry's diatribes, but I have to say that he hit the nail pretty much on the head when he said: <fixed><fontfamily><param>Courier New</param> No, the largest barrier is that *everything* is not a package, so that *anyone* can make a decision on what "unnecessary" means to them, without shooting anyone else in the foot. In other words, if you are trying to define "unnecessary", then you are addressing a symptom, rather than the problem. The "make installworld" target defines what is and is not in "The Base System". For better or worse, this is an Ultimate Truth. Without tackling the problem at that level, it's unlikely that it will ever be solvable. </fontfamily></fixed> That truly is the more fundamental problem here and something which can be addressed independently of libh, even if the initial target is to simply create a series of FreeBSD packages for each subcomponent and then one or more meta-packages which define the "base" and simply contain a list of dependencies. With the ``extract-in-place'' directive I added to pkg_add(1) some time back, it's even possible to have these packages pretty much do the right thing without having to go through /tmp, it would just require a little smarts in sysinstall to detect them and avoid extracting them in the same fashion as the other packages. Since there never has been a "packaged distribution" of FreeBSD available, that's simply never been worth doing. I personally would smile on any effort to deconstruct src/release/Makefile with any eye towards packaging the bits entirely differently. The packaging strategems currently employed there are based around the 1.2MB *floppy* for godssakes, and if ever there were a bit of legacy baggage worth looking into, it's that stuff. FreeBSD is rapidly growing past its original and humble goals of being a good x86-only operating system and looking at a whole bunch of new technologies (KSE, SMP, fair-share scheduling, etc), all of which is essentially growth along a single technical axis, and it's simply regrettable that its growth in terms of release engineering technology has essentially stagnated around work done in the early-to-mid 90's. Growth along multiple axis can easily occur without being mutually conflicting, so who's gonna step up to the plate? Don't look at me, I did so much of the first system that I always come down with second-system-syndrome when I try to get involved in such things. :-) - Jordan On Friday, August 2, 2002, at 08:44 AM, Zak Johnson wrote: <excerpt>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? -Zak To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message </excerpt>-- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-8-613267768-- 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?E6F026CE-A644-11D6-B7BD-0003938C7B7E>