[ATrpms-devel] suspend2 kernel provides

[Axel Thimm]

On Tue, May 16, 2006 at 11:43:47AM +0200, Alexander Bergolth wrote:
> >>>That's broken anyhow, because any kernel 2.6.16 will satify it. That's
> >>>why kmdls don't rely on the kernel Provides. So your best bet is to
> >>>remove that dependency from the specfile.

> Thanks for the pointer.
> But it looks like this behavior isn't caused by the kmdl but by the
> kernel package itself:

Yes, and that's why it won't change :/

> So if the kernel packages only provided the exact "<version>-<release>"
> capability, dependency checking would work, right?

Yes. So all that is needed is to convince Fedora Core's current kernel
maintainer and Fedora Legacy to change that ... :)

> > Try rpm -Uhv ...
> > 
> > and you will see that the original package will be removed under your
> > nose. rpm magic ... ;)
> 
> Not on my system:
> 
> [... test w/ modified "kernel" package ...]

That doesn't count, you need to test with the kernel or at least copy
the Provides we're talking about. All you demonstrated is that the bug
is in the kernel rpm's Provides. :)

> > I hope you concur with me, that depending on "kernel" is really
> > severely broken?
> 
> I agree partly. ;)
> But only because of the way the provides are specifies in current kernel
> packages.

Yes, but "current" = "that's the way it's always been, and no report
has changed that".

And changing this means changing for all kmdl-supported distros, not
only FC6. There isn't enough momentum to get this fixed, so we have to
live with it.

> Again I only agree partly. ;)
> I claim that if kernel-suspend2 would provide only "kernel =
> <version>-<<release>" but not "kernel = <version>", things would work a
> lot better.

By covering up the bugs of the openafs rpm? The depedency of openafs
on "kernel" is buggy, it just doesn't show up directly. Only when
you'll install kernel-2.6.16-A and openafs for 2.6.16-B will you get
hit. That's what this broken dependency allows you to do.

Even worse, regardless of what kernel-suspend2 will provide
kernel=2.6.16 always wins (it's effectively a wildcard provides like
kernel=2.6.16-*). So any normal kernel rpm would already satisfy it
again. That's just provocing funny bugs that users and ATrpms
maintainer would be seeking for ages to find :)

And finally: Previous ATrpms kernel packages (up to FC2) did indeed
have a proper (different) provides to match. This was diverging from
the RH kernel rpms and necessitated the use of what you called briding
rpms. This was so overly complicated that it wore us out (it worked
for the users, but it gave headaches to the maintainers). So it was
finally dropped.

Depending on vmlinuz is so much easier and stable, did I mention that?
:)

On Tue, May 16, 2006 at 12:08:38PM +0200, Alexander Bergolth wrote:
> OK. According to the kernel module guidelines for Fedora Extras...
>   http://www.fedoraproject.org/wiki/Packaging/KernelModules
> 
> ... a kernel-module should require "kernel-%{_target_cpu} =
> ${verrel}${variant}", i.e. something like
> 
> -------------------- snip! --------------------
> Requires:         kernel-i686 = 2.6.14-1.1776_FC4
> -------------------- snip! --------------------
> 
> Since current kernels only provide kernel-%{_target_cpu} including the
> exact "<version>-<release>" string, this would work perfectly, wouldn't it?

So what about RHEL3 and RH7.3/RH9 which are often used clients for
openafs?

The issue is with having a portable scheme that works everywhere. And
that what kmdls do.

But this should be resurrected for the kernel rpms at ATrpms, I agree.
-- 
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.atrpms.net/pipermail/atrpms-devel/attachments/20060517/90423835/attachment.bin