Steve Kemp wrote: > I've thought about different solutions to this problem several times, > but I can't quite convince myself that there is a perfect solution. > > I find that the Debian xen-kernels are unsuitable for me on a lot > of machines, so I use custom kernels and source-compiles of Xen. > > I can see that copying /lib/modules/$(uname -r) might be OK since > it will do the right thing on machines which are running a Debian > image, or on a self-made Xen installation. If you could be happy > with that not being controlled by dpkg then I'd make that change.
It's better than the current situation, but any files that cruft would
find that are not managed by dpkg is a nonstarter for me on any system
that I maintain. And IMHO, the more systems one maintains, the more rules
like that make sense, and so it's even more important with xen..
Here's an approach that tries to be smart about using linux-modules
packages iff available:
linux_modules_package="linux-modules-$(uname -r)"
if chroot ${prefix} apt-cache policy ${linux_modules_package} 2>/dev/null; then
installDebianPackage ${prefix} ${linux_modules_package}
else
# Fall back to copying over modules from the host to the new
# system.
mkdir -p ${prefix}/lib/modules
cp -au /lib/modules/$(uname -r) ${prefix}/lib/modules
fi
--
see shy jo
signature.asc
Description: Digital signature
