Created attachment 147499 [details]
Fix -debug and -debug-devel Provides

This is fixed in the pending update.

Which version should it be fixed in?  I'm eyeballing 2.6.20-1.2928.* in CVS (the
latest Rawhide I can see) and the fix isn't applied in it yet.

2.6.19-1.2911.fc6 and 2.6.19-1.2288.fc5 are fixed.

But thanks for reminding about 2.6.20 ones...

Created attachment 148327 [details]
Fix -debug, -PAE-debug, -debug-devel and -PAE-debug-devel Provides

This is still unfixed in 2.6.20-1.2935 and now the newly added PAE-debug and
PAE-debug-devel seem to have developed the same problem.  Updated patch against
current Rawhide CVS (that I can see at the moment, that is) attached.

Created attachment 151429 [details]
Fix -debug, -PAE-debug, -debug-devel and -PAE-debug-devel Provides

Still unfixed in 2.6.20-1.3038.fc7.  Is there something more I could do to get
this applied?  Should be pretty much a no-brainer.

*** Bug 238328 has been marked as a duplicate of this bug. ***

Also affects FC6 now, see bug 238328.

applied to F7. Chuck, want to do the same for the next F6 update?

*** Bug 240236 has been marked as a duplicate of this bug. ***

F-7 looks good (based on specfile inspection and some test builds only), but
FC-6's latest update has at least one remaining issue;
kernel-PAE-debug-2.6.20-1.2952.fc6.i686 provides:

    kernel-i686 = 2.6.20-1.2952.fc6PAEdebug

...but should provide instead:

    kernel-i686 = 2.6.20-1.2952.fc6PAE-debug

There should be no "-" within the release string, so 1.2952.fc6PAE-debug
should not be used, but 1.2952.fc6PAEdebug is ok.

regards,

Florian La Roche

That would be inconsistent with all the other variants which have the uname -r
output of the corresponding kernel in their "Provides: kernel-$arch = ...", and
would pretty much render this particular Provides useless.

Seems you now refer to the "name" portion and not the "version-release" string.
Like e.g.: name = version-release

regards,

Florian La Roche

No, I don't.  Don't think in terms of %{version}-%{release} on the right side of
this Provides - as far as kmodtool and kernel module packages packaged according
to the current kernel module packaging guidelines are concerned, it's just a
string, always required with a "=" relation.  rpm doesn't mind the extra dash
either.

This particular Provides is expected to be like this for subpackages (for
2.6.20-1.xxxx.fcX kernel on i686):
- (the "normal" kernel): Provides: kernel-i686 = 2.6.20-1.xxxx.fcX
- PAE: Provides: kernel-i686 = 2.6.20-1.xxxx.fcXPAE
- PAE-debug: Provides: kernel-i686 = 2.6.20-1.xxxx.fcXPAE-debug
- foo-bar-quux-baz: Provides: kernel-i686 = 2.6.20-1.xxxx.fcXfoo-bar-quux-baz
- smp: Provides: kernel-i686 = 2.6.20-1.xxxx.fcXsmp

The right hand "version-release" string is parsed by rpm into a version part
and into a release part, so 2.6.20-1.xxxx.fcXPAE-debug is parsed into
version = 2.6.20-1.xxxx.fcXPAE and release = debug.

The kernel is currently the only rpm package getting this wrong. I know
for the most part this just stays a string is not overly important, but
we start misuing the version-release string a bit here.

regards,

Florian La Roche

I know, but it doesn't matter in the case this particular Provides was added for.  

Declaring it "wrong" now and changing it when it does actually work as designed
and intended would result in need for nasty, fragile workarounds in tools and a
lot of 3rd party packages for no practical gain I can think of.

Perhaps the Provides should have been something like
"kernel(i686:2.6.20-1.xxxx.fcXPAE-debug)" (unversioned in rpm terms) or another
format that would have communicated the intent better; the intent is just to
have an easy to use way to depend on the exact kernel the modules were built
for.  Now, with the special case with dashes it is still possible, but backwards
incompatible and harder/more fragile to use.

When I resolve F7 metadata with Yum on FC6, these special dependencies
fail for me (haven't rebooted into rawhide/F7 yet):

[...]
--> Running transaction check
--> Processing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug for package:
kmod-em8300-PAE-debug
--> Finished Dependency Resolution
Error: Missing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug is needed by
package kmod-em8300-PAE-debug


https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00303.html

Reproduced.  No problems with yum if kernel-PAE-debug is installed separately
first, then "yum install kmod-em8300-PAE-debug".

This bugzilla looks resolved for me, at least current Fedora-devel has all
the right bits in there.

Can we close this bugzilla?

regards,

Florian La Roche

I think the provides for the kernel-debug-devel package is causing issues when installing akmods:

# repoquery --provides kernel-debug-devel
kernel-debug-devel = 3.16.6-200.fc20
kernel-debug-devel(x86-64) = 3.16.6-200.fc20
kernel-debug-devel-x86_64 = 3.16.6-200.fc20
kernel-devel = 3.16.6-200.fc20+debug
kernel-devel-uname-r = 3.16.6-200.fc20.x86_64+debug
kernel-devel-x86_64 = 3.16.6-200.fc20+debug

--> Processing Dependency: kernel-devel-uname-r for package: akmods-0.5.1-3.fc19.noarch
---> Package kernel-debug-devel.x86_64 0:3.16.6-200.fc20 will be installed

Why does the kernel-debug-devel package have kernel-devel* provides?  Or should akmods require something different?

Hi , I study this issue some say ago , so I have in fresh memory 
akmods.spec got : 

Requires:       kernel-devel-uname-r

repoquery --repoid=updates --whatprovides kernel-devel-uname-r  
kernel-debug-devel-0:3.16.6-200.fc20.x86_64
kernel-devel-0:3.16.6-200.fc20.x86_64

and yum choose kernel-debug-devel , as Richard Shaw wrote: (if the Fedora maintainer will agree) would be better, make sure the non-debug package (kernel-devel) has a higher NEVR than the others, perhaps by appending ".1" to the release ...


repoquery --arch=i686 --repoid=updates --whatprovides kernel-devel-uname-r  
kernel-PAE-devel-0:3.16.6-200.fc20.i686
kernel-debug-devel-0:3.16.6-200.fc20.i686
kernel-devel-0:3.16.6-200.fc20.i686
kernel-PAEdebug-devel-0:3.16.6-200.fc20.i686

for i686 yum have to choose one of four kernel-devel