Skip site navigation (1)Skip section navigation (2)
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>