[Fedora-packaging] Re: kmdl proposal and kmod flaws

[Axel Thimm]

On Tue, Aug 08, 2006 at 08:06:49PM -0400, Jack Neely wrote:
> On Wed, Aug 09, 2006 at 01:42:10AM +0200, Axel Thimm wrote:
> > On Tue, Aug 08, 2006 at 06:29:41PM -0400, Jack Neely wrote:
> > > I will veto Axel's current plugin as it uses regular expressions to
> > 
> > Let the plugin wars begin ;)
> > 
> > > Most of my hesitation regarding the uname-r in name scheme is because
> > > this was fully discussed before and we decided on something different.
> > > FESCo ratified it and we were going to be able to support in in FC6 and
> > > RHEL 5.
> > 
> > Decisions can be wrong especially when it affects complex matters that
> > affects only few packages like less than 0.5% of all packages. The
> > important thing is that any decision needs to be reevaluated from time
> > to time and possibly changed. Otherwise you kill development.
> > 
> > > There is another important trade off here.  Right now
> > > up2date/yum/whatever is able to suck down upgraded kernel modules just
> > > like upgrades to a new kernel.  This works without modifications to the
> > > depresolvers because the package name is always the same.
> > 
> > No, you forget that this scheme either nukes or conflicts/coinstalls
> > the new modules. Imagine running up2date/yum w/o any kmod-plugin
> > support on RHEL5 and nuking your GFS (or AFS) modules away. You (and
> > your clients) will not be amused.
> 
> 
> Okay...walk me through this then:
> 
> Assuming no yum plugins or other mess.
> 
> A new kernel is available that corrects some random remote DoS.  How do
> I get all 1300 machines to pull down the new AFS modules?

It's in the wiki, but here it comes again:

o current kernel module scheme w/o any special depsolver handling:
  - broken on rpm level, inherits on all depsolvers
  - Modules of the current kernel get nuked whether you reboot into
    the new kernel or not
  - Module upgrades within the same kernel get blocked due to file
    conflicts 
  - OR module upgrades within the same kernel get coinstalled and
    module-init-tools can flip a coin to find out what to choose
  + but the new kernel gets its kernel modules (and only the new
    kernel ...)

o proposed kernel module scheme
  + old and current kernels remain untouched by new kernels and kernel
    modules for new kernels
  + Proper upgrades of kernel modules within a kernel
  - new kernels don't get associated kmdls coinstalled

Now compare and judge for yourself :=)

Next thing to consider is whether and how to fix the remaining issues:

o current kernel module scheme special handling:
  - no special handling possible with rpm cli will remain forever
    broken
  - needs to both mark kernel module packages as coinstallable (which
    they are not) and to perform non-rpm comformant depsolving
  - Is required for all depsolvers and is a MUST otherwise depsolvers
    reduce your system to ashes

o proposed kernel module scheme special handling:
  + nothing needed for rpm cli
  + Obviously less than half the code needed than for the current
    scheme, rather trivial coding, easy maintenance
  + Is NICE TO HAVE, absence does not break running system

Compare again. :=)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060809/0ad16424/attachment.sig>