[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Fedora-packaging] Re: atrpms kernel modules

On Tue, Jul 25, 2006 at 03:00:35PM -0700, Toshio Kuratomi wrote:
> Apologies for posting into the wrong subthread of this monster, I
> already deleted the relevant mail.
> If one of the major issues with the current kmod spec is that neither
> rpm -U nor rpm -i work correctly, shouldn't that be corrected?  If the
> module could install into something like this:
> instead of:
>   /lib/modules/KERNELVER/extra/MODULE/MODULE.ko
> wouldn't that bring the behaviour of kmods inline with that of the
> kernel?  (Use rpm -i for normal operations, rpm -U if you don't believe
> in Murphy).

The issue is with the package's name and evr, not its contents.

And there are no "normal" operations possible unless you use

o non-kernel/non-kernel-module packages:
  Always UPGRADE (e.g. remove the old packages): rpm -U

o kernel packages:
  (co)INSTALL, don't remove the current kernel, possibly also not a
  couple more kernels: rpm -i [1]

o kernel-module packages:
  Do replace kernel modules for the same kernel, but don't touch
  kernel modules of other kernels:
  So it's a mixture of simultaneous UPGRADE/INSTALL operations.

The latter is also the problem. Given this two-dimensional evr-space
where verticals and horizontals are to be handled with upgrades and
(co)install operations you get into trouble with trying to project the
space onto one dimension. You get the different operations needed

The only way out is to defuse one dimension, e.g. remove it from rpm's
line of sight, and that is the kernel's version. Moving the uname-r
into the package's name makes the packages behave properly both within
one kernel and across different kernels with rpm -U, e.g. kmdls are to
be handled like typical packages, for example (omitting releases, only
versions for simplicity):

rpm -Uhv foo-kmdl-2.6.20-2.i686.rpm

will install kernel module foo in version 2 for kernel 2.6.20 w/o
affecting kernel modules for kernels 2.6.19 or 2.6.21, but still
replacing possibly previous versions of foo (say version 1) for kernel

That's exactly the desired functionality on rpm CLI level already!

And all depsolvers already handle the part with upgrading the kmdls
within the kernel. What they need to be tought to make the picture
perfect is to install matching kmdls upon kernel upgrades.

[1] With yum's installn it's not quite true, there is a delayed rpm -e
    lingering around waiting for enough kernels to gather to remove
    the oldest.
Axel.Thimm at ATrpms.net

Attachment: pgpSyTBAcwEqJ.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]