It was discussed on the mailing lists, but so we can track it. It would be nice to package kdelibs' apidocs separately, ideally as a noarch pkg, containing (mostly): /usr/share/doc/HTML/en/kdelibs-apidocs Attached is a sample implementation we use with the kde-redhat pkgs that will create a noarch kdelibs-apidocs when built with rpmbuild -bb --target=noarch kdelibs.spec
Created attachment 123427 [details] sample kdelibs.spec used by kde-redhat
Oops, just noticed kdelibs-3.5.0-5 packages these as -docs. Any chance of renaming to -apidocs to be compatible? (It's not that big of a deal, we can change to match, but it'll just be a little more painful)
it's fixed in next kdelibs rebuild
any chance of kdelibs-apidocs being noarch?
Too late now to change to noarch. native arch builds are now in the wild. The crappy part is that yum (seems to) always prefer native arch versions of same-named pkgs, even though there are newer noarch ones available. Case-in-point: Using 'yum update' upgrade to kde-redhat's kdelibs-apidocs-3.5.2.noarch pkg fails.
Only alternative I see (I strongly think kdelibs-apidocs *should* be noarch) is to rename the package (go back to kdelibs-docs?), and have it Obsoletes: kdelibs-apidocs
In the meantime, please use a *versioned* Obsoletes, like Obsoletes: kdelibs-docs < %{epoch}:%{version}-%{release}
The problem is that our build system does not allow to build package arch and noarch simultaneously with only one srpm! For doing that, it requires 2 srpm sources which we really don't want and always avoid. To comment #5: it seems a bug in yum and needs to be fixed.
Can you at least use a versioned Obsoletes?
sure, it's now in CVS.