strip FreeBSD a bit

[Terry Lambert]

Ah, -chat!  Well known for religious discussions...

Andreas Klemm wrote:
> On Wed, Sep 10, 2003 at 12:11:06AM +0200, Alex de Kruijff wrote:
> > On Sun, Aug 31, 2003 at 08:50:10AM +0200, Andreas Klemm wrote:
> > > Christer,
> > >
> > > I think its a bad idea to remove components from FreeBSD that
> > > everybody would expect in a BSD.
> >
> > I think there has to be a clear reason if components where removed. This
> > still doesn't mean that it couldn't come installed by default. It just
> > meant useing the package / port system. Why sould we not use it?
> 
> Because breaking BSD into too many little pieces has contra
> productive side effects...
> 
> All components that you put into the ports system are not
> directly maintained by the FreeBSD committers anymore.

That's just historical cruft; you might call it "traditional" to
throw something into ports, so that the people who want to get
rid of it can pretend that "someone" is going to maintain it,
going forward, when really what they want to do is get rid of it,
but they can't do it honestly, without pissing people off, so
they do it dishonestly by moving it to a port.

History doesn't have to repeat itself forever, though; there's
no reason you can't replace the Makefile in /usr/src/bin/sh
with one that includes bsd.port.mk instead of bsd.prog.mk.

In other words, there's no reason to move something that goes
into a ports-type build system out of the main repository, except
that it ruins the fun of the people who want to be able to throw
things away by making them ports, and pretending that that means
that they are automatically removed from the main source base
by the repo-fairy as a direct consequence of them including the
wrong 3 letters following the 'p' in their Makefile.



> Don't forget that not all port committers are FreeBSD committers.

It doesn't matter.  We're talking about changing Makefile's,
not removing things from the repository entirely just because
of some preconceived prejudice about how they're built.

In fact, mostly we don't give a damn about the "port" part of
things, we are much, much more interested in the "package"
aspects, in terms of being able to pkg_delete pats of the base
system, or pkg_add them back in, when we decide that the shiny
new GPL'ed version of whatsis from Linux isn't so shiny or so
new as we first thought, and we want our BSD version back.


> You need more experience in coding if you maintain a complete
> OS then to make something to fit under ports control to make
> it simply run.
> 
> If the software is under CVS control, then many eyes watch the
> code from time to time by software review and such ....

Nobody is talking about changing any of that.


> And as I said, if I make a complete OS installation then I
> expect to get a complete OS in the first place.

Nobody's talking about changing defaults, either... only about
providing more options than were previously there.


> And with a complete OS I mean a BSD with its roots and tradition
> so that at least it contains all those bits and bytes, that usually
> every commercial OS / BSD has or that has been in it since years !

You mean like UUCP and XNS networking, right?  8-) 8-).


> 2 or 3 years I installed a RedHat for testing ... well the
> basic installation didn't contain even "sed".
> 
> And things like this I strongly dislike.

We all agree: RedHat's choices in defaults for meta-package
dependency lists for bas installations using default options
are terrible.

So don't copy their model when you build *your* meta-package
dependency list for your base system package, and it's not a
problem you have to worry about.


> I even dislike that UUCP had to go into ports ... Now you don't
> have a standard tool in standard OS install like cu to connect
> to serial ports what need for job in the networking area.

It pissed all of us off.


> But at that time nobody wanted to take care of it, so it has to
> go out of CVS not to produce bitrod.

You mean "no one to who FreeBSD was willing to grant commit bits
wanted to take care of it".

And there is no such thing as "bitrot", there are only people who
fail to maintain all the code that is impacted by their changes
to their pet subsystems.  That's also what happened to LFS, when
the unified VM and buffer cache went in: a failure to maintain the
code while making changes.  It used to be that the BSD credo was
"if you break it, you now own it, and it's your responsibility to
fix it".


> > > I think you touch areas here like tradition ...
> > >
> > > In Linux its another thing, they don't have such a tradition,
> > > since Linux is only a kernel and Linux never defined a Linux
> > > basde system. So there you can discuss of having sendmail,
> > > exim, postfix or qmail installed by default or not.
> >
> > The way the kernel is related to the distribution is totaly irrelevant.
> > If you looking for traditions here they sould be in the various
> > distributions.
> 
> What I mean with tradition is, that an Operating System exists
> since a long time and you are used to expect this and that in
> it ...
> 
> And I repeat, Linux is only a kernel, therefore every distribution
> maker can't have something like a "normal tradition" since Linux
> never defined something like a base system for Linux.
> 
> The effects are as I described, missing sed in standard installation
> like red hat and bloated installations all around. Many different
> flavours of tools in the different Linux installations.
> 
> Though the BSD also differ in much things I have the feeling that
> they are still much closer to each other than the many many Linuxes
> I played with in the past: Slackware, RedHat, SuSE, Knoppix, Gentoo,
> Debian.

Here I absolutely, 100%, totally agree with Andreas.

If you want a default other than the traditional BSD default, then
it's up to you to create your own *non-default* meta-package list
to use with your installs.

And yes, I'd list UUCP in the default meta-package list, and the
people who want it to stay in coventry can create *their* version
of a meta-package list to use with *their* installs.

-- Terry