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