Fredrik Jonson wrote:
> Jörg-Volker Peetz wrote:
> > Bob Proulx wrote on 01/14/2015 06:25:
> > > Fredrik Jonson wrote:
> > > > I'm trying to find obsolete packages on a system that's been
> > > > dist-upgraded. How would you [do that without using] aptitude?
> > >
> > > Try this:
> > >
> > > apt-show-versions | grep -v uptodate
> >
> > This doesn't show all the results "aptitude search ~o" finds on my system
> > [...] This shell command works for me:
> >
> > awk '/^Package: / {print $2}' /var/lib/dpkg/status | sort |
> > (awk '/^Package: / {print $2}' /var/lib/apt/lists/*_Packages | sort |
> > comm -23 --nocheck-order /dev/fd/3 -) 3<&0
>
> Interesting. The shell command above indeed does include more packages that
> are obsolete on my system too.
>
> As far as I can tell the difference is that your awk command
> includes packages that have been removed but not purged, while
> apt-show-versions ignores non-purged packages that have only config
> files left.Hmm... If you have removed but not purged packages they aren't installed packages. So this difference isn't surprising. I think everyone should be worried about removed but not purged packages too. Otherwise they are a source of lint that builds up on a system. They are a very useful inbetween status for packages. Local modifications can remain on the system in /etc and the package can be quickly installed again and resume from the previous configuration. But between major release upgrades they cause problems. For example files in /etc/init.d/* previously did not have LSB tags and now they are required. For example at some point in the future files from the pre-systemd era will be problematic in a post-systemd one. For example there has been a lot of problems with php packages loading shared libraries where there isn't a way to conditionally load them based upon existence. (Currently /etc crontabs always conditionally load based upon file existence to work within the removed but not purged state of things for example.) Having a good backup mitigates the fear of purging a package. With a full backup of /etc any package can be purged and then if the local admin wants to reverse that and install the package again the previous configuration can be restored from backup. Using a tool such as etckeeper also keeps track of files in /etc. That is very useful. I have become a convert to using etckeeper. That also provides a good safety net for purging packages. The easiest way to find removed but not purged is with grep. dpkg -l | grep ^rc Or since I like grep-status and friends this can be done precisely using it too. grep-status -sPackage -n -FStatus "deinstall ok config-files" Purging lib packages should be very safe. After reviewing the list I often do it on the command line. dpkg --purge $(grep-status -sPackage -n -FStatus "deinstall ok config-files" | grep ^lib) I do that for non-lib packages too but only after reviewing the list. Bob
signature.asc
Description: Digital signature
