[ATrpms-devel] suspend2 kernel provides

[Alexander Bergolth]

Hi!

On 17.05.2006 03:31, Axel Thimm wrote:
> 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 ... :)

Maybe that's why the newer distros provide kernel-i686 (and alike) only 
with the exact version-release string and the Fedora Extras packaging 
guidelines suggest to use this capability for kernel modules...

>>> 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.

Concerning openafs, it looks like we have agreed about a feature-check 
now: check, if the kernel (or kernel-devel) package against which the 
kmdl is built, provides "kernel-<arch>" and if it defines it, use it.

See
https://lists.openafs.org/pipermail/openafs-devel/2006-May/013850.html
and the following mails, if you are interested...

>> 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 :)

That's a good point, this is indeed a problem...
So it looks like we should change the strategy for kernel-modules from:
"use Requires: kernel-<arch> if available, otherwise use kernel" to
"use Requires: kernel-<arch> if available, otherwise don't specify any 
kernel-requirement"

> 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.

Yeah, I can imagine that.

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

I don't know the official statement on that topic.
However, while reading up on those dependency issues, I found a bugzilla 
report where Jeff Johnson suggested to use a file dependency!

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112825

But this may have changed since this recommendation is more than two 
years old...

>> 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.

A feature check would help. But yes, for those old distros it seems the 
best solution to simply not specify any kernel-dependency.

> But this should be resurrected for the kernel rpms at ATrpms, I agree.

Cheers,
--leo
-- 
-----------------------------------------------------------------------
Alexander.Bergolth at wu-wien.ac.at                Fax: +43-1-31336-906050
Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria