Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Sep 2014 10:02:18 +0800
From:      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 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.

> Basically it's possible to manually remove (delete) things
> when you _know_ what you are doing. Removing manpages is
> such a possible task that probably won't hurt. Have a
> usable source tree at hand, so you can "make install" if
> you accidentally removed something important, that's why
> don't remove "make". ;-)

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.

> The best way to tune an installation is at install time.

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 

> 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.

> 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.

> 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.

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 

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. I did find the file locations (I 
think it was /var/db/freebsd-update somewhere) and run an awk script to 
clean up those files, but the freebsd-update process still opened up 
every file, leaving me with a 'quit editor' keystroke - ZZ from vi 
turned out to be the fastest, but over hundreds of files, that's still 


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