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
Attachment:
signature.asc
Description: Digital signature