On Sun, 2006-12-17 at 01:52 -0600, Manoj Srivastava wrote: > On Wed, 13 Dec 2006 10:20:56 +1100, Robert Collins > <robertc@robertcollins.net> said: > > > The basic problem is that presence of a kernel package does not > > imply presence of the desired patch/enabled feature in that package, > > nor that the running kernel is the installed one. > > Assumptions: the machine in question is running a packaged > kernel. This is not required; people can download kernels from > kernel.org and (gasp) _not_ use make-kpkg. Its not -required- that any of the software on a machine be packaged. Users can (gasp) build and run their own $software - e.g. squid, apache, whatever. But - we cannot expect the packaging system to ensure that requirements are met for *any* unpackaged software. I think its a fair and proper assumption that the stack of software is all packaged: its very easy to build a packaged, vanilla kernel - and doing so can generate appropriate information for dpkg. > > What you need to do is twofold: depend upon the presence of the ABI > > required, if you can get the kernel package maintainers to add an > > Assumption: all machine4s that install your package are going > to be running official kernels. None of my machines ever do. No, thats not an assumption. Done appropriately, the ABI data emitted would be done via make-kpkg, and be able to be generated for kernel.org kernels as well as debian 'official' kernels. > > appropriate provides: entry, and secondly handle the absence of that > > ABI gracefully at runtime. Given you didn't add any 'assumption:' lines here, I presume you agree with that point? -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part