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.

  • Are you leaving the kernel meta package installed? – jordanm Jun 30 '13 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 '13 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 '13 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 '13 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 '13 at 9:04
2

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.

  • 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 '13 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.