[PATCH 1/1] [Jaunty] UBUNTU: clean up module dependancy information on package removal/purge

[Ben Collins]

On Thu, 2008-12-04 at 10:17 -0800, Tim Gardner wrote:
> Andy Whitcroft wrote:
> > Bug: #399773
> > 
> > Currently when we purge (dpkg -P) a kernel image we emit the following
> > warning and fail to clean up the /lib/modules/<version> directory:
> > 
> >   rmdir: failed to remove `/lib/modules/2.6.28-1-ub-generic':
> > 							Directory not empty
> >   dpkg - warning: while removing linux-image-2.6.28-1-ub-generic,
> > 	directory `/lib/modules/2.6.28-1-ub-generic' not empty so not removed.
> > 
> > This may be triggered by a number of things:
> > 
> > 1) recently depmod started producing a new map file modules.seriomap,
> >    which we do not know about and do not purge,
> > 2) if the kernel-header files are installed there is a build symbolic
> >    link in this directory,
> > 3) if the kernel-source files are installed there is a source symbolic
> >    link in this directory, and
> > 4) it is possible to have an updates directory here from the dkms
> >    system.
> > 
> > When these are encountered we fail to clear the directory and our
> > unconditional directory remove will fail leading to this missleading
> > warning.
> > 
> > When examining the prerm and postrm handling for this package a number
> > of things are apparent:
> > 
> > 1) the main dependancy information modules.dep is removed on a normal
> >    package removal (non-purge),
> > 2) the remaining dependancy information modules.aliases,
> >    modules.symbols, and modules.*map are only removed on a purge, and
> > 3) during a purge we attempt to remove files belonging to other
> >    packages the build and source links (although the code will fail to
> >    remove them as they are links and not files).
> > 
> > If we consider the official difference between a module remove and a purge
> > we find that a purge is meant to also take away any local configuration
> > files for this package.  These dependancy files are not configuration
> > files for the module loader, those are all in /etc/modprobe.d these are
> > all data generated by the install of the kernel package and indeed are
> > all overwritten without comment on a reinstall.  Basically they should
> > be considered in the same manner as the modules.dep file and removed
> > when the package is removed.
> > 
> > This patch fixes up this whole lot, it:
> > 
> > 1) moves removal of all dependancy related files over to prerm with the
> >    removal of modules.dep,
> > 2) adds the new modules.seriomap file to the list of files to be removed, and
> > 3) removes build and source from the removal list.
> > 
> > This also fixes the original issue (the warning) by moving removal to the
> > prerm phase, so that the files are removed before the primary directory
> > deletion is attempted.  This allows the normal reference counting for
> > this directory to work as normal.  The directory being removed when all
> > packages storing files within are removed from the system.
> > 
> > Signed-off-by: Andy Whitcroft <apw at canonical.com>
> > ---
> >  debian/control-scripts/postrm |   23 -----------------------
> >  debian/control-scripts/prerm  |   18 +++++++++++++++---
> >  2 files changed, 15 insertions(+), 26 deletions(-)
> > 
> 
> I think this looks right according to Debian policy. Everything being
> removed is either part of the original package or was generated as a
> side effect of the install.
> 
> Ben - since you're our resident DD, what do you think?

The kernel headers symlink is supposed to be there, and shouldn't cause
this message (as the directory and symlink are under dpkg control).

There are a lot of other reasons this could happen (dkms modules) that
the kernel package should not assume it can cleanup.

IMO, the kernel package really shouldn't cleanup anything it is not
responsible for. Depmod files are good, since they can only be built
when the kernel image is installed (and are only important when it is).