2

I've created a Rubygem to help with removing old kernels that have built up over years and are eating disk space. (My laptop had 19 kernels on it alone, and on a small SSD...)

I want to use apt-get or dpkg as the uninstaller since some people will not have aptitude installed and I do not want users of the gem to have to install anything.

The problem comes when some users do use aptitude for other things. Scenario:

  1. User uses my gem which successfully apt-get purge's the kernel packages.
  2. User starts aptitude in interactive mode for any reason,
  3. User presses the 'g' key (Download/Install/Remove Pkgs) immediately without marking any changes, -->
  4. aptitude re-downloads and re-installs the packages that apt-get had purged.

Currently, the gem uses apt-get purge <packages> to purge the kernel packages. (Seen here.) I also tried with dpkg --purge <packages>, but the result is the same, aptitude still wants to reinstall them.

I've read through the entire aptitude manual and googled many things, no dice.

Maybe I could programmatically manage aptitude's marked/unmarked packages list if I could find where it is (although I'd prefer a cleaner solution.) I assume it's not /var/lib/dpkg/status or else there would be no disparity?

dpkg-query shows the package status as Not and the desired state as Unknown.

deKernel$ dpkg-query -l linux-image-3.2.0-39-generic
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                       Version                                    Description
+++-==========================================-==========================================-====================================================================================================
un  linux-image-3.2.0-39-generic               <none>                                     (no description available)
deKernel$

It's possible to go into aptitude and manually un-mark those kernel packages and the problem disappears, however this is obviously quite impractical.

Improve this question
7
  • Are you leaving the kernel meta package installed?
    – jordanm
    Jun 30, 2013 at 23:51
  • Aptitude probably has them marked as automatically installed. My solution would be to try aptitude first, then fall back to apt-get. (Why do you need Ruby for this?)
    – tripleee
    Jul 1, 2013 at 4:39
  • @jordanm That's a good thought, I checked into it but no I'm not, dpkg-query -l shows the linux-headers package in the same states as the specific packages.
    – damick
    Jul 2, 2013 at 8:09
  • @tripleee I suppose that's a possibility, but it seems a bit patchy & would introduce unpredictability. Why do I need Ruby? I don't, but I like Ruby & it was faster than writing it in shell. Also, try listing your boot directory, copying one of the kernel numbers, then typing dpkg-query -W *[paste kernel number]*, then typing apt-get purge [copy and paste in each of the 3 different kernel package names]. Now do all of that 15 more times for each other kernel you want to remove. Now do that on ~70 host machines that have been running Ubuntu for ~5 years and built up a lot of kernels. :)
    – damick
    Jul 2, 2013 at 8:31
  • @jordanm Also, dpkg-query -l does show the linux-headers-generic package as installed, but it's version matches my current kernel like it's supposed to.
    – damick
    Jul 2, 2013 at 9:04

1 Answer 1

Reset to default
3

aptitude has it's own package state database /var/lib/aptitude/pkgstates, which unfortunately seems to be rather undocumented. It stores a block like this for each package:

Package: bash
Architecture: amd64
Unseen: no
State: 1
Dselect-State: 1
Remove-Reason: 0

I believe state 1 means installed, white state 3 means not installed. I also have a few packages with state 4 on my system, but I can't figure out what that means.

I believe your problem is a result of on inconsistency between the dpkg database /var/lib/dpkg/status and the aptitude database /var/lib/aptitude/pkgstates. According to this post pkgstates is supposed to reflect "the user's 'intended' state for the package[s]", so aptitude probably believes that the user wants these packages to be installed even though apt-get has just removed them.

It seems like the best solution for your problem is to do what tripleee suggests: use aptitude if it is installed, and if not, fall back to apt-get.

Improve this answer
1
  • Like you guys suggested, I will be adjusting the Rubygem to use aptitude if it's installed, apt-get if not. Thank you for this excellent clarification!
    – damick
    Oct 24, 2013 at 22:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .