[Fedora-packaging] Re: Mail voting on kmdl adoption

[Thorsten Leemhuis]

Tom 'spot' Callaway schrieb:
> On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
>> Tom 'spot' Callaway schrieb:
>>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
>>>
>>> So far, the only technical reason that I've heard mentioned here against
>>> adding kver to Name is that it would make debuginfo more complicated for
>>> kmod packages (and I believe that someone posted a workaround method).
>> You forgot the biggest "issue" (note the quotes): All the depsolvers 
>> would need special handling to install kmods for newly installed 
>> kernels. That works out of the box with the current scheme and IMHO is 
>> an important advantage of the current standard. Yes, there exists a 
>> yum-plugin already that handles it. But we would need something for 
>> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
> 
> I'm not sure I see how this automatically works in the current kmod
> scheme

Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5

kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo

Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
---

(or alternately, how it doesn't work in the kmod+kver scheme).

Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-2.6.17-1.2157_FC5-1.2

kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed
to the repo

Yum will install:
kernel-2.6.17-1.2171_FC5

kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new
package for yum whit a different name
---

>>> In fact, I suspect that kmodtool could even include the necessary magic.
>> Sure, that would be possible. But we'll hit other problems after this 
>> major scheme change. We probably hit some in the old livna days, but I 
>> forget most of them already (sorry -- maybe I can skip though bugzilla 
>> to fresh up my mind). But I think sticking to the current scheme and 
>> solving the "install-conflicts" problem together with the kabi stuff 
>> would be the better idea.
> 
> Again, I tend to defer to people who know more about packaging kernel
> modules than I do.

I'll outline my idea in a more detailed mail I'll start preparing now.

CU
thl