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

[Tim Gardner]

Andy Whitcroft wrote:
> On Fri, Dec 05, 2008 at 02:24:59PM -0500, Ben Collins wrote:
>> 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).
> 
> I concur, and I hope that is exactly what I have done with this patch.
> Made the kernel package only responsible for removal of the depmod
> files, and ensured it does not touch the build or source links.
> 
> The removal of the updates directory and dkms subdirectory I have fixed
> in the dkms package, also against this bug.
> 
> -apw
> 

Then thats an ACK.

-- 
Tim Gardner tim.gardner at canonical.com