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

[Axel Thimm]

On Mon, Aug 14, 2006 at 03:49:50PM -0400, Jack Neely wrote:
> On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
> > On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
> > > 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.
> > 
> > o the yum-plugin for kmods is broken and possibly cannot be rectified,
> >   see mail to Jack
> 
> Ah, breakage.  Tisk, tisk.  Solve this one:

Altready solved since long in ATrpms' everyday life.

> Installed are:
> kernel-2.6.17-1.2157_FC5
> kmod-foo-2.6.17-1.2157_FC5-1.2
> foo-1.2-1_FC5
> 
> where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2
> 
> Yum has:
> kernel-2.6.17-1.2171_FC5
> kmod-foo-2.6.17-1.2171_FC5-1.3
> foo-1.3_FC5
> 
> And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3.

You probably have a typo here, the first item is supposed to end with
1.3

> So what happens here?

You are trying to do both a kernel upgrade and module version
upgrade. You only get into that situation because you skipped the
intermediate step (which can happen simultaneously): You don't only
build mod-foo-2.6.17-1.2171_FC5-1.3, you also build
kmod-foo-2.6.17-1.2157_FC5-1.3.

> # yum update

Updates everything to 1.3

> We reboot into our new kernel and 10 minutes later we see that foo is
> totally broken because there's not a kernel module for it.

Only if you messed up by simultaneous upgrading kernel and module
version w/o offering interim versions.

> # yum install kmod-foo-2.6.17-1.2171_FC5
> 
> Yum pulls in foo-1.3 to meet the requirements.  Now we experiance pain
> as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed.

Note that kernel modules have two version (evrs to be exact):

o the kernel version: follows the kernel's example and allows going
  back and forth

o the module version: follows a conventional package's upgrading

If the new kernel is broken you can reboot to the previous one. If the
module itself is bogus you need to downgrade as you do with
conventional packages.

> This affects both schemes.  Is this a technical problem that can be
> fixed?

Not a problem with kmdls.

> > You make it sound like the kmdl scheme needs special handling, while
> > it's the other way round. The kmdl scheme does never jeopardize your
> > existing install and this inherits to all depsolvers and rpm. While
> > the kmod scheme violates basic rpm ordering rules and tried to rectify
> > with in-depsolver special handling *and* plugins and has already been
> > shown to be broken by design.
> 
> The kmdl scheme *does* require depsolver modifications to work.  I must be
> able to push out updated kernel modules to my clients in an automated
> fashion.  

Once again arguing in circles, but repetions works:

o kmod scheme: requires workaround in yum core and requires a yum
  plugin to not start nuking running kernel modules or file
  conflicting or partial overwrites

o kmdl scheme: requires trivial yum plugin to have new kernel installs
  automatically coinstall kmdls

Note both say "requires", but the first is requires as in "requires,
otherwise havoc is programmed", while the latter is "requires for
added comfort"

Yes, let's allow kmdls to become more comfortable, but don't compare
neccessity of (trying to) unbreak things with adding automatism.
-- 
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://lists.fedoraproject.org/pipermail/packaging/attachments/20060815/8b3a0353/attachment.bin