[Apt-Rpm] Problem with kmp-packages on the openSUSE buildservice

[Panu Matilainen]

On Tue, 8 Jan 2008, Johannes Kastl wrote:

> Hello,
>
> Panu Matilainen wrote:
>
>> Kernel packages are special, and kernel module packages are even worse -
>> there's no way to generically handle them from a package manager with the
>> rpm dependencies currently available. Handling them always requires some
>> extra logic (whether built into depsolver or via plugin-type mechanism) to
>> have a prayer of a chance of getting it right. Zypper has at least some
>> knowledge about them (based on a quick look at the source), while apt
>> certainly has not.
>
> OK.
>
>> What happens here is as follows (a very typical situation with kernel
>> module packages, no matter how they're packaged except for dkms):
>> - you ask apt to install truecrypt
>> - truecrypt depends on "truecrypt-kmp" virtual provide
>> - there are several packages providing "truecrypt-kmp", ie
>>    truecrypt-kmp-default, truecrypt-kmp-bigsmp and whatnot
>> - apt sees no difference in the packages providing "truecrypt-kmp" so
>>    it picks up whatever it happens to encounter firsts
>> - in this case, it happened to be truecrypt-kmp-bigsmp, that in turn
>>    requires kernel-bigsmp so apt thinks it needs to pull it in
>
> Why does apt not install the kmp-package that fits in with the running
> kernel?

Because apt has no notion of "running kernel". There's no way to 
generically map running kernel to a given package - it always requires 
distro-specific extra logic.

> Is there no way to check which package would need the smallest
> amount of extra packages?

For this kind of situation, no, not currently. It would of course be 
techinally possible - smartpm might even do it (dunno if it does, but its 
depsolve algorithm is far more advanced than that of apt). But it wouldn't 
actually fully solve the case with kernel (modules).

The kernel is unlike anything else on the system in that that having it 
installed doesn't mean its capabilities are actually usable. You can
have more than one kernel installed (several versions, several variants 
such as xen and default kernel). When something requires a kernel module, 
should that module be installed for your current running kernel, the 
latest one (which you're about to reboot to) or ... well, the only generic 
answer is: install the module for all installed variants and their 
versions. Which probably isn't what you *really* wanted either :)

>> To fully automate it, one would have to write a Lua-extension that knows
>> about SuSE kernel and kmp packaging.
>
> Why not just a script checking which kernel is installed? Which of
> course sounds easier than it will be, I guess.

It's certainly doable via Lua extensions (that's what the 
"upgrade-virtual" extension I referred to earlier is all about, only it's 
tailored for Fedora and derivates and different kernel + kernel module 
scheme), Zypper has the SuSE-specific logic hardcoded into it. But again, 
there's no way to do it generically.

>> Other options require more or less manual work: stuffing all non-relevant
>> kmp packages to RPM::Ignore is one possibility, but since RPM::Ignore
>> requires full package names instead of accepting regex's, it's somewhat
>> cumbersome. Simplest workaround just to provide the kernel module name
>> manually in install (eg "apt-get install truecrypt truecrypt-kmp-default")
>> but that's not exactly optimal either :-/
>
> Would pinning work in this case? Pinning kmp-bigsmp-packages (or simply
> anything with *bigsmp* in it) to not getting installed?
>
> Something like:
>
> Package: *bigsmp*
> Pin: *
> Pin-Priority: 50
>
> (I guess the Pin: line needs more info, but just an example).

Pinning and priorities don't seem to help in this case, there's no good 
way to express this situation with them (and I wouldn't count out bugs on 
top of that :) What does appear to work is stuffing the unwanted kernels 
to RPM::Ignore - eg something like this in /etc/apt/apt.conf:

RPM {
     Ignore {
         "kernel-bigsmp";
         <.. insert any other unwanted variants here ..>
     }
};

 	- Panu -