Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Sep 2014 14:55:58 +0200
From:      Polytropon <>
To:        Gregory Orange <>
Subject:   Re: Remove distribution sets
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, 16 Sep 2014 10:02:18 +0800, Gregory Orange wrote:
> On 15/09/14 18:09, Polytropon wrote:
> > On Mon, 15 Sep 2014 16:07:30 +0800, Gregory Orange wrote:
> >> Can one remove distribution sets from FreeBSD 8.x?
> >
> > The system doesn't provide a _dedicated_ means to do this.
> Thank you (despite it being less than ideal news) - I wondered, but 
> couldn't find anything stating it as such.

I had thought of a "make deinstall" command for the
particular parts in the /usr/src directory tree, but
you can only do "make install" for most components.
Removing them, it seems, has to be done manually.

> Yes I neglected to mention this URL: 
> Noone responded to edogawaconan regarding a register of the components 
> installed. I'll have a play with it, and particularly with 
> feebsd-update.conf and see how I go.

This involves doing an upgrade of the system, but if
this is to be done anyway, it _might_ work and remove

> > The best way to tune an installation is at install time.
> -snip-
> Agreed. I've just heard back from hosting provider: They only have one 
> 8.3 OS image to install, and it has this extra material in it. They're 
> not planning a 8.4 image, so I'll have to get us to 9.x or later at some 
> point.

I'd suggest, if possible, to follow 10.0 / 10.1 as soon
as possible. You could probably even do a "network install",
preparing a customized 10.0 image with stuff left out, and
then "copying" it to the server "over the present install".
This of course has to be done with a backup and an emergency
recovery plan in mind. ;-)

> > It's also possible to "prepare" a stripped-down system
> > elsewhere and then use it to replace the installation in
> > question.
> I wonder if I'll need to pursue that. I'd rather not.

But it seems to be the easiest thing, "easy" in comparison
with the alternatives (like manually removing parts from the

> > A comparable way is provided via freebsd-update where parts
> > to be subject of an update can be selected using its configuration
> > file; see "man freebsd-update.conf" for the "Components"
> > keyword.
> This might be my best option.

It _should_ remove the "outdated" components and _not_
install their new counterparts if the configuration file
says so. I'm not sure how it handles "hidden" dependencies,
but the distribution parts should be quite independent of
each other, so for example removing manpages does not break
anything, it's just that there are no manpages anymore;
removing sendmail, on the other hand, will render the whole
system unusable.

> > Probably you won't save much disk space anyway...
> I don't care about the disk space. The aim is twofold:
> 1. Reduce any extra content that widens the risk profile on a machine. 
> If code is present, there is some chance for it to contain bugs, which 
> leads to some chance of a security risk.

Yes, that is a very important aspect (which I'm scared of
whenever I have to deal with stock Linux installations).
Also for dedicated systems, I tend to strip down the OS
and the kernel, as I'm doing source updates anyway from
a different system, so for example it's no big deal if
there is no C compiler on the target system, no troff,
and no loadable kernel modules.

> 2. Ease upgrades. Already the machine has a custom kernel which I need 
> to replace with generic. The upgrade process requires a lot of manual 
> intervention (see below), and I'll be dealing with a number of these 
> machines.

This also sounds interesting. For binary updates, using
a custom kernel makes things more complicated, but if
you trim your freebsd-update.conf and rely on "preprocessed"
parts, updates should be quick and easy.

> Manual intervention:
> lots of prompting with "these files don't match, what do I do?" and 
> frustratingly, an editor session opens up to compare - in the vast 
> majority (all but a handful) of cases the differences are just the 
> header line which doesn't matter to me.

There is something comparable when doing source upgrades:
You can configure mergemaster not to annoy you. The file to
do this is /etc/mergemaster.rc, see "man mergemaster" for
details. This part of the upgrade process can be adjusted
to be less frustrating. :-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>