[ATrpms-devel] suspend2 kernel provides

[Axel Thimm]

On Mon, May 15, 2006 at 09:39:18PM +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.
> 
> If the kernel-module requires kernel =
> 2.6.16-1.2111_1.99.rhfc5.cubbi_suspend2_8k, only a kernel with that
> loong version-string (including ...cubbi_suspend2_8k) will satisfy the
> dependency. Or am I missing something?

Any 2.6.16 kernel will satisfy it. It's a surprise at first, then you
bugzilla it only to find out that dozens of surprised folks have
bugzilla'd it before you and due to legacy reasons this won't
change. Just try it, install along a non-swsusp2 kernel and suddenly
the openafs package will be (falsely) happy.

Up to date no RHL/FC/RHEL kernel ever provided sensible "kernel"
entities to depend upon. Anything depending on that is really broken
(although you can argue that the breakage stems from the vendor, but
it's broken nevertheless, and won't be fixed at vendor level, so one
better drops this approach).

> I did mean the name of the _capability_ that it provides, not the name
> of the rpm. If you only add
> Provides: kernel = 2.6.16-1.2111_1.99.rhfc5.cubbi_suspend2_8k
> instead of
> Provides: kernel-suspend2 = 2.6.16-1.2111_1.99.rhfc5.cubbi_suspend2_8k
> but still name the RPM kernel-suspend2-..., the package won't be 
> considered as
> an upgrade, will it??? (At last unless the second package defines an 
> obsoletes-tag.)

It will even w/o. This is a known and ugly bug that has been declared
a feature. It breaks already at rpm level:

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

Bottom line: A virtual Provides is as good as naming the package such,
e.g. it contains an implicit Obsolete.

> I did some basic tests to verify my assertion, at least apt and smart 
> will not suggest to upgrade a package if there is another one with a 
> different name that provides a higher version of the same capability:

Try rpm -Uhv ...

and you will see that the original package will be removed under your
nose. rpm magic ... ;)

> $ rpm -qp --provides rpmtest-1-1.i386.rpm
> rpmtest = 1-1
> $ rpm -qp --provides rpmtest-alternative-2-1.i386.rpm
> rpmtest = 2-1
> rpmtest-alternative = 2-1
> 
> If rpmtest-1-1 is installed, apt and smart won't consider 
> rpmtest-alternative as an upgrade even though it provides a higher 
> version of the same capability.

But when you ask them to install it, suddenly rpmtest vanishes w/o any
notice. Imagine this happening with the kernel :)

> >>I believe there should be at least an additional
> >>Provides: kernel = %{suspend2version}
> >>... to avoid having to rewrite all third party spec-files...
> > 
> > Only the broken specfiles :)
> 
> No, that's unfair. You cannot expect a third party rpm-packager to know
> that you are building _kernel_-rpms that provide kernel-suspend2 instead
> of kernel.

I hope you concur with me, that depending on "kernel" is really
severely broken?

> I'd really like to do that but I don't believe it is the right way to
> modify every third party src-rpm (if it's not really necessary).

It really is. And I guess that probably only openafs and a couple
other rpms have this idiom.

To be honest: That kernel-suspend2 didn't export a kernel = provides
was an accident. But looking back, I'm rather glad it doesn't as it
only covers over broken dependencies. What you are after is really
fixing openafs' dependencies, and doing that by exporting "kernel" is
really broken.

> Then I'm using the following "bridging"-rpm to satisfy the
> dependency:

ATrpms and PlanetCCRMA had bridging rpms once :)
But they didn't help much. Instead rewriting the dependencies not to
depend on any "kernel" Provides was the right answer in the long run.
-- 
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/20060516/19701c82/attachment.bin