Search Criteria
Package Details: remove-orphaned-kernels 1.1.2-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/remove-orphaned-kernels.git (read-only, click to copy) |
|---|---|
| Package Base: | remove-orphaned-kernels |
| Description: | pacman -Rs orphaned kernel and driver packages, excluding currently-running. |
| Upstream URL: | https://aur.archlinux.org/packages/remove-orphaned-kernels/ |
| Licenses: | GPL |
| Submitter: | chrisjbillington |
| Maintainer: | chrisjbillington |
| Last Packager: | chrisjbillington |
| Votes: | 2 |
| Popularity: | 0.56 |
| First Submitted: | 2020-02-28 17:34 (UTC) |
| Last Updated: | 2022-03-22 22:10 (UTC) |
Dependencies (2)
- python (python32AUR, python37AUR, python310AUR)
- sudo (fake-sudoAUR, polkit-fakesudoAUR, sudo-gitAUR, doas-sudo-shimAUR, doas-sudo-shim-minimalAUR, sudo-hgAUR, sudo-selinuxAUR, fudo-gitAUR)
Latest Comments
G3ro commented on 2024-03-18 14:22 (UTC)
@chrisjbillington Thx for the answer. No pressure; maybe I will also look into it myself, but sadly I am a very bad programmer :D.
Yes parsing version numbers seems like a good idea; I remember there is a pacman hook for kernel install somewhere, maybe that could be somehow combined. But (if a general implementation is too complicated, which it probably is) I think the focus should be on your packages, because thats what most people probably would use this for.
Also OT, but thank you very much for the packages so far, you saved me a lot of time already (whenever arch broke somehow ;)).
chrisjbillington commented on 2024-03-18 00:42 (UTC) (edited on 2024-03-18 21:17 (UTC) by chrisjbillington)
@G3ro It uninstalls all that are not explicitly installed or depended on by another package, and that are not the currently running kernel. If you're using the linux-*-versioned-bin packages, then the latest kernel package is a dependency of the metapackage, and that's what prevents it from being uninstalled.
As such the code is currently unaware of how "new" a kernel is and has no concept of ordering. I could make it more aware of this, but that would require having it make some more assumptions. It could use install dates, but that isn't necessarily what you want. It could parse version numbers, but then it would need to be aware of the possible kernel packages there are - lts, zen, hardened, vanilla, and keep the latest n packages of each. Perhaps that is the way to do it. It could infer these kernel variants from the names of the kernels you have installed, rather than needing to have an explicit list. Yes, I think that would work.
As for UI, I imagine I'd just add a command line argument
--keep <n>or something like that, retaining the current behaviour by default.I don't have the time to implement this right now, but I think it would work fine. Feel free to prod me in a few weeks if I haven't done so yet.
G3ro commented on 2024-03-18 00:01 (UTC) (edited on 2024-03-18 00:02 (UTC) by G3ro)
Maybe I don't understand this package correctly, but AFAIU this deletes all kernels except the newest one, correct?
Would it be possible to create a version to keep only lets say the latest two or three kernel versions installed?
Flammkuchen commented on 2022-03-23 00:53 (UTC)
Gern geschehen. Works like expected now. Thanks for the fast fix.
chrisjbillington commented on 2022-03-22 22:12 (UTC)
Dankeschön Flammkuchen, apologies for not being aware this code was LANG-dependent. I've made the change so that subprocesses whose output is to be parsed are called like this:
Could you verify that it works for you?
Flammkuchen commented on 2022-03-22 21:12 (UTC)
This script only works if the language is set to English. If your system is not set to English, use
LANG=C remove-orphaned-packagesI would prefer this to not be necessary. This could be done like in https://stackoverflow.com/questions/51293480/how-to-call-lc-all-c-sort-from-python-subprocess
In this case it doesn't have to be LC_ALL, LANG is enough.