Deb wrote: > I'm intimidated by the bug reporting system and kind of afraid to use it, > but I'll read up on it thoroughly and see whether I can file a bug report > without getting yelled at (or filing a duplicate by mistake). LOL! I have been yelled at in so many bug reports that I am desensitized to it. I rather expect that every time I file a report that I am going to get griped at for it. So I sympathize. I have stopped filing reports against some packages due to this. But that shouldn't stop people from doing so when it is the right thing to do. But I completely understand if you want to avoid the conflict. In which case discussing the issues here will motivate someone (perhaps even me) to file a bug about it. I have cruft installed but I don't run it. It is one of those grand experiments that is perpetually in development that doesn't seem to have been finished off yet. I would hope that someone who actually uses and likes cruft would jump in and help with it. > I just reinstalled that library as per your instructions and plan to rerun > cruft when I have time to check whether it still gives me the same missing > dpkg. I"m betting it won't. I should have also mentioned this in my message. Let me mention it now. # apt-mark markauto libept1.4.12 Normally libraries are installed as dependencies of other packages. But if you install any package manually that package will be marked as manually installed. By installing that library manually it was marked as manually installed. Meaning that it would never be a candidate for "autoremove" cleaning later. In order to keep the system tidy (and you are running cruft so I know you care about keeping it tidy) it should be marked as "auto" again. If you wish to review the list you can list all of the manually installed packages and all of the automatically installed packages. They are long lists so I suggest browsing them with the 'less' screen pager. $ apt-mark showmanual | less $ apt-mark showauto | less The packages that are marked as automatically installed become candidates for 'autoremove' once the package that "Depends" upon them is upgrade to a newer library and no longer depends upon it. # apt-get autoremove I have been recommending 'etckeeper' as a good package to check the contents of /etc and all of the "conffiles" there into version control. You might consider installing it. It will then commit every system package change and all /etc file changes into version control. Meaning that with etckeeper installed I recommend purging packages instead of removing them. # apt-get autoremove --purge With etckeeper (and/or with good backup, backup is always important) then packages can be purged removing the conffiles from /etc too. That is important in keeping a system tidy too. $ dpkg -l | grep ^rc Those packages have been removed but have /etc conffiles left behind for you to possibly reinstall and use them again. To be completely clean those packages should be purged and those /etc conffiles removed with them. This isn't really critical until doing major release upgrades such as Squeeze 6 to Wheezy 7 or from Wheezy 7 to Jessie 8. > Thanks for the link to the manpages bug. I read it and am not concerned, > unless I should post in that bug report that I've duplicated the findings. I wouldn't add to the bug report unless there is additional information or you want to poke the maintainer to move things along. This is one of those, yes it is a bug, but just sitting there on disk it doesn't badly affect things. It just isn't tidy. Bob
Attachment:
signature.asc
Description: Digital signature