On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote:
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
---
Example:
kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo
- yum update will bail out of file conflicts
- OR will happily coinstall if the paths are disambiguated (worse)
Example (yum w/o special plugin and special kernel-modules handling in
core):
- kmod-foo-1.2.2.6.17-1.2157_FC5 get nuked. Oops ...
--
Axel.Thimm at
ATrpms.net