Locate pkg's not used

bsdtux

bsdtux

hello all, I am trying to locate all the packages that I installed that haven't been touched in a while. My first thought was to just get a list of packages and when they were installed


Bash: 
for app in `pkg info | awk '{print $1}'`;
do
    pkg info $app | grep -B 4 "Installed on";
done
and then start looking at their dependencies so that I can see what installed what and if I need it anymore. However this seems horribly inefficient but this was the only way I knew how to accomplish the clean up that I am looking for. I did look through the man pages of pkg-info. I also checked out pkg-audit because that also sounds like something auditing might be able to tell me but I didn't find flags that stood out to me.

So with that said does anyone have a better way to accomplish this clean up task on my machine (it is a laptop) or am I going down the best route currently and I just need to accept that this is not going to be a 15 - 30 minutes task and instead will be more involved
 
bsdtux said:
...get a list of packages and when they were installed ... and then start looking at their dependencies so that I can see what installed what and if I need it anymore.
Click to expand...
Something like pkg autoremove maybe? pkg(8)
Code: 
autoremove
         Delete packages which were    automatically installed    as dependen-
         cies and are not required any more.
 
bsdtux said:
I am trying to locate all the packages that I installed that haven't been touched in a while.
Click to expand...
On second thought, I'm not sure if the suggestion in the previous post is what you are looking for. Can you be more specific?

Sidenote, instead of
Bash: 
for app in `pkg info | awk '{print $1}'`;
do
    pkg info $app | grep -B 4 "Installed on";
done
simpler, shorter pkg info -a --full | grep -B3 "Installed on" (see pkg help info for [{...,full,..}])
 
T-Daemon said:
On second thought, I'm not sure if the suggestion in the previous post is what you are looking for. Can you be more specific?

Sidenote, instead of
Bash: 
for app in `pkg info | awk '{print $1}'`;
do
    pkg info $app | grep -B 4 "Installed on";
done
simpler, shorter pkg info -a --full | grep -B3 "Installed on" (see pkg help info for [{...,full,..}])
Click to expand...

I have used pkg autoremove. What I am really looking for is any package that I have installed but have not used. I am trying to slim down my install base but I have a feeling that most of the packages that I have installed are probably dependencies to other packages
 
bsdtux said:
What I am really looking for is any package that I have installed but have not used.
Click to expand...
That's going to be tricky, you can have a look in /usr/local/bin for example. If you see something you might want to remove you can find out which package installed it by using pkg which <file>. You can then look at the dependency chain by using pkg info -r <packagename> and pkg info -d <packagename>.
 
You can invoke pkg leaf
(Leaf port: has dependencies but no other ports depend upon it.). [EDIT] Better use pkg prime-list . Choose from there which packages you don't want anymore. Afterwards clean up
unfulfilled dependencies with pkg autoremove . pkg alias might interest you.
 
Maybe turning the problem on its head would be easier.
Start by the assumption that all packages are unused. Then go one by one and ask the question: "Have I used one of this package's files recently?". If the answer is yes, then mark the package for keeping.
Once you go through all the packages, you would have a list of all packages that have been used recently. Loop once more through this list and mark all their dependencies for keeping.
Remove everything else.
 
Neither pkg leaf nor pkg prime-list appears to be documented somewhere.

I am maintaining a textfile with the toplevel applications I want to have installed (including comments why that is needed).
Then, a list of those ports that have no dependencies (which is probably what pkg leaf provides) should be identical to that list. Everything else can be removed.
 
PMc said:
Neither pkg leaf nor pkg prime-list appears to be documented somewhere.
Click to expand...
FWIW, it is documented somewhere:
Code: 
root@kg-core2# pkg help leaf
`leaf` is an alias to `query -e '%#r == 0' '%n-%v'`
root@kg-core2# pkg help prime-list
`prime-list` is an alias to `query -e '%a = 0' '%n'`
 
  • Thanks
Reactions: PMc
We are all talking about interesting technical details of package installation. But bsdtux' question is much simpler and not technical: He has installed a package called "foo". He no longer knows why he did that, and he wants to know whether he is actually needing or using it.

"pkg prime-list" is a good starting point: these are packages that can maybe be removed (the others are needed because of dependencies). But even among those, they don't know which one they are using.

Here is a suggestion: Make sure the file system that /usr/local is on is mounted with atime support (easiest done by editing /etc/fstab, then rebooting, although it can be done with a remount, but that may be too advanced). Then watch the atime of all executables there, and see which ones don't get used in a month? Then use "pkg which" to find out which packages own files that don't seem to get used at all, then use "pkg info -l" to find out what other files that package provides, and see whether any of those get used.

Better idea: Keep a log book of all administrator actions you ever take, like a diary. In there you will find entries like "20191006 Installed the foo package using the command pkg add foo, for my new project of counting purple elephants". Then later you can read that log book, and make an informed decision.
 
ralphbsz said:
Here is a suggestion: Make sure the file system that /usr/local is on is mounted with atime support (easiest done by editing /etc/fstab, then rebooting, although it can be done with a remount, but that may be too advanced). Then watch the atime of all executables there, and see which ones don't get used in a month?
Click to expand...

Yes. Thank You. :) This is exactly the use case I was waiting for after reading this frustrating discussion.

Your idea implies that one does not do a full backup within a month. This problem is known, and therefore backup solutions offer to use the O_NOATIME flag to the open() call, so that atime does not get updated during backup.
*If* the operating system supports it.

I for my part am a big friend of atime, as it helps to solve these and similar problems, like: which of my config files is actually read on software startup? But nowadays one would wish to switch that off for certain tasks where it does no good and just wears the drives.
 
(Warning: off-topic)

For the most part, atime is a silly and useless artifact. It is hardly ever used. It's only really mainstream use is HSM systems, where files that are not accessed frequently are moved to different storage. But doing that with just atime is hard and dangerous and inaccurate. If you want to do HSM, integrate it into the file system (some do), and do it correctly. Furthermore, atime is a file-system internal concept: it is about how the file system optimizes where to store things. There is no need to have information about that in the API between the user application and the file system.

Given that atime is hardly ever used, it just wears out disks, uses up performance (not much), and makes life harder for file system implementors.

Unfortunately, once in a while one does need it. And given that there is no reliable or standardized way to get the information "which file was accessed when, why, where, and how", we have to use atime occasionally. You listed two cases where it makes sense.
 
ralphbsz said:
We are all talking about interesting technical details of package installation. But bsdtux' question is much simpler and not technical: He has installed a package called "foo". He no longer knows why he did that, and he wants to know whether he is actually needing or using it.

"pkg prime-list" is a good starting point: these are packages that can maybe be removed (the others are needed because of dependencies). But even among those, they don't know which one they are using.

Here is a suggestion: Make sure the file system that /usr/local is on is mounted with atime support (easiest done by editing /etc/fstab, then rebooting, although it can be done with a remount, but that may be too advanced). Then watch the atime of all executables there, and see which ones don't get used in a month? Then use "pkg which" to find out which packages own files that don't seem to get used at all, then use "pkg info -l" to find out what other files that package provides, and see whether any of those get used.

Better idea: Keep a log book of all administrator actions you ever take, like a diary. In there you will find entries like "20191006 Installed the foo package using the command pkg add foo, for my new project of counting purple elephants". Then later you can read that log book, and make an informed decision.
Click to expand...
This right here is a great idea. Since this is my Test machine to help me learn freebsd at a deeper level I think doing a new installation and keeping a entry like you said would be best. Maybe even pipe the installation out to a txt file so that I can track the dependencies on a per package basis.

As for the /usr/local I did install my laptop with ZFS so I don't remember seeing /usr/local mounted in /etc/fstab.
 
Whether mounted as a separate file system or not, /usr/local exists, and packages/ports are installed there.

If you use root on ZFS, then you probably don't see all the details in /etc/fstab. Use ZFS commands for that.
 
You must log in or register to reply here.
Back
Top