# Remove components post-installation



## edogawaconan (Dec 25, 2008)

A long time ago I installed freebsd with all distribution sets.

Now I want to remove some of the sets (notably catman, info and proflibs). Is it possible? 

(or I missed something, somewhere?)


----------



## brd@ (Dec 25, 2008)

Yeah, you could find the tarballs that contain these sets and use something like:

```
tar -t <tarball>
```
So you know what files are included in it and make sure you want to remove them. Then you could probably do something like this to remove them:

```
tar -t <tarball> | xargs rm
```


----------



## gnemmi (Dec 26, 2008)

Amazing UNIX Guru wisdom ...

Thank you .. really.


----------



## edogawaconan (Dec 26, 2008)

doesn't seem to cleanly remove the component (namely freebsd-update upgrade still recognizes these components: world/dict world/info) which I want to remove.


----------



## tnpimatt (Feb 21, 2017)

For the sake of other search engine visitors, the reason it may not have worked cleanly for edogawaconan is likely because the file paths in the component tarballs are relative. If he wasn't in / when he ran the command, it wouldn't have deleted the files. Here's an example command that will remove the doc sources from a FreeBSD machine:


```
cd /
export FREEBSD_VERSION=`/bin/freebsd-version | /usr/bin/cut -f1-2 -d'-'`
export COMPONENT_URL="ftp://ftp.freebsd.org/pub/FreeBSD/releases/`uname -m`/$FREEBSD_VERSION"
fetch -o - $COMPONENT_URL/doc.txz | tar -tzf - | xargs rm
```

If you're removing the lib32 distribution, you might also have to remove some flags like so:


```
tar -tzf lib32.txz | xargs chflags noschg
tar -tzf lib32.txz | xargs rm
```


----------



## ShelLuser (Feb 21, 2017)

tnpimatt said:


> For the sake of other search engine visitors, the reason it may not have worked cleanly for edogawaconan is likely because the file paths in the component tarballs are relative.


First, you're responding to an almost 10 year old thread, just saying 

I'm not sure which post you're referring to, but if you meant the last post about freebsd-update then the cause is a completely different one: /etc/freebsd-update.conf also needs to be told about any removed components. See freebsd-update.conf(5) for that.


----------



## tnpimatt (Feb 21, 2017)

> First, you're responding to an almost 10 year old thread, just saying

Please be nice. I *already* pointed out my awareness.

>> the reason it may not have worked cleanly
>the cause is a completely different one

Apparently you missed the paragraph where I described _who_ my post was aimed to benefit.

There is no uninstaller for FreeBSD components such as doc, games, src, ports, and lib32. By default, freebsd-update.conf has _Components src world kernel._ Within world are optional installs (doc, games, lib32) and freebsd-update does filesystem checks to determine whether it should update them. Without touching freebsd-update.conf at all, uninstalling the no-longer-desired components as I described *does* exactly what the OP and other search visitors likely want: removes the components and prevents freebsd-update from updating them.

FreeBSD users who have FreeBSD installed for them (think: cloud provider) or don't wish to re-install to get rid of components may well search for how to remove those components and land on this thread. My post was for them.


----------



## kjpetrie (Dec 4, 2017)

tnpimatt pointed me in the right direction but (fortunately) his code didn't work for me, possibly because my root user doesn't use Bash and also because rm only removes directories if the recursive option is used. If he had used that option I think I would have lost my whole system as the first error I got was 
	
	



```
rm: ./: is a directory
```
!

Definitely carry out the steps manually to ensure you only remove the parts you want to remove.

```
rm -r
```
 is irreversible.


----------



## marian_cerny (Feb 9, 2021)

Since FreeBSD 12.0 freebsd-update shows there is `world/doc` installed, even when it is not. Because since FreeBSD 12.0 the `doc.txz` is an empty archive:



> FreeBSD 12 no longer includes the 'doc' set, it was postscript files from the 1970s. The file was removed from the MANIFEST file, so everything should stop referencing it, but a valid empty tar is there in case an application wrongly depends on it being there.



The list shows a single directory `./`, that's why @kjpetire (above) saw `rm: ./: is a directory` error.

In case you want to be sure there are no files from the previous `world/doc` component, you can check and/or remove the following directories:

```
/usr/share/doc/papers/
/usr/share/doc/psd/
/usr/share/doc/smm/
/usr/share/doc/usd/
```
In case you want to delete `kernel/generic-dbg` coponent than you can delete the following directory:

```
/usr/lib/debug/boot/kernel/
```
(Or you the whole `/usr/lib/debug/` directory. It's not present if you have no debug components.)


----------



## kjpetrie (Feb 9, 2021)

Thank you for your contribution. However, it is incorrect. Firstly, this happened long before FreeBSD 12 came out, so what is or isn't included there is irrelevant, and secondly, whatever the reason, my purpose was to point out how dangerous a 9-year-old instruction was on the system as it was 3 years ago. From what you write it sounds as if it remains equally dangerous now.


----------



## marian_cerny (Feb 11, 2021)

You are right that


> that's why @kjpetire (above) saw `rm: ./: is a directory error`.


was incorrect. Your post is from 2017 and FreeBSD 12.0 was released in 2018. 

However I think all the other info is correct. I came to this post because I wanted to get rid of `kernel/generic-dbg` component. I also noticed that `world/doc` component is installed which I never install, however after little research I found out that it's listed there because the component is empty and one can ignore it on FreeBSD 12+.

The reason you have seen that error is that every `.txz` archive contains an empty directory `./` as the first item. I agree it might dangerous to follow any instructions on internet. However, neither the original 9 years old post nor tnpimatt's 3 years old answers seems that dangerous to me, because they didn't use the recursive option. So the error is in fact only a warning. I personally didn't run those instructions blindly. I have listed the contents of an archive and deleted the files manually (for me it was just a single directory `/usr/lib/debug/boot/kernel/`).


----------

