https://bugzilla.redhat.com/show_bug.cgi?id=1111691
--- Comment #13 from David Nichols david@qore.org --- (In reply to Michael Schwendt from comment #12)
Versioned Provides do not imply that you must use '>='. It would be perfectly acceptable to only use '=' in dependencies.
$ rpm -q --provides audacious-libs|grep api audacious(plugin-api) = 40 audacious(plugin-api) = 41 audacious(plugin-api) = 42 audacious(plugin-api) = 43 audacious(plugin-api)(x86-64) = 40 audacious(plugin-api)(x86-64) = 41 audacious(plugin-api)(x86-64) = 42 audacious(plugin-api)(x86-64) = 43
$ repoquery --whatrequires 'audacious(plugin-api)(x86-64)'|wc -l 19
All require the latest API version 43:
$ repoquery --whatrequires 'audacious(plugin-api)(x86-64) == 43'|wc -l 19
Versioned capabilities, however, allow for versioned queries with "rpm", repoquery and other package tools (if not considering Requires, Obsoletes, Conflicts and BuildRequires):
Does anything in the repos support a newer plugin API already? For example, the next development release in alternative packages?
$ repoquery --whatprovides 'audacious(plugin-api)(x86-64) > 43'|wc -l 0
Apparently not.
Does anything in the repos support an older plugin API? For example, a compat package?
$ repoquery --whatprovides 'audacious(plugin-api)(x86-64) < 40'|wc -l 0
Apparently not.
Assume we need to drop support for API 41 and older, does anything in the repo require any old Plugin API?
$ repoquery --whatrequires 'audacious(plugin-api)(x86-64) <= 41' |wc -l 0
Apparent not.
Assume the next release drops support for API older than 50, does anything in the repo still require any older API?
$ repoquery --whatrequires 'audacious(plugin-api)(x86-64) < 50'|wc -l 19
All, but 3rd party repos not included in the query.
[...]
I don't claim the "Provides: qore-module-api-0.18" is not sufficient for what it is being used so far -- an exact dependency on that thing. There are 14 such Provides in the package already. There is a version in them, but in the wrong place. That's unusual and inconvenient.
What to do about it also depends on 3rd party packages that already use these strict dependencies and how many shall be included in the package collection. In that case, proper Obsoletes tags would need to be added anyway. There could also be a transition to versioned Provides only for new API versions, while the old ones would be kept as long as they will still be supported.
[...]
OK I have updated the package to use the versioned capabilities and declare the old unversioned capabilities obsolete.
the new declarations are as follows:
Provides: qore-module(abi) = 0.18 Obsoletes: libqore5 < 0.8.12 Obsoletes: qore-module-api-0.18 Obsoletes: qore-module-api-0.17 Obsoletes: qore-module-api-0.16 Obsoletes: qore-module-api-0.15 Obsoletes: qore-module-api-0.14 Obsoletes: qore-module-api-0.13 Obsoletes: qore-module-api-0.12 Obsoletes: qore-module-api-0.11 Obsoletes: qore-module-api-0.10 Obsoletes: qore-module-api-0.9 Obsoletes: qore-module-api-0.8 Obsoletes: qore-module-api-0.7 Obsoletes: qore-module-api-0.6 Obsoletes: qore-module-api-0.5
Any comment on fedora-review licensecheck.txt and rpmlint.txt?
licensecheck.txt: I missed this one before - there were two GPL files taken from glibc (getopt_long.cpp and getopt_long.h) that I had forgotten about. These files are not used in the Linux build, but regardless their presence precludes releasing Qore under an optional MIT license.
I have just replaced them with BSD-licensed variants (taken from FreeBSD). The BSD-licensed versions will be present in the next release.
The mass of files with LGPL headers are from Qore, and this source has been now released under a less restrictive MIT license.
I will update all these source files to reflect the new licensing status and also the option to use them under the GPL and LGPL (Note: the qore library allows itself to be initialized under the GPL which allows it to load binary modules also tagged as under the GPL; if the qore library is not initialized under the GPL then GPL-tagged modules cannot be loaded).
This will take some time, so I will post another comment when the updated source packages are available.
rpmlint.txt: The spelling errors can be ignored in my opinion - all except "Qore" (name of the project) are valid according to the New Oxford American Dictionary.
+ qore: manual-page-warning: I removed the undefined macros
+ libqore: obsolete-not-provided: I have to admit I do not understand the rpmlint -I explanation for this warning - AFAIK I should declare the old library name as obsoleted by the new one in case anyone has the old version installed
+ libqore: only-non-binary-in-usr-lib: this is due to the Qore-language module files being stored under lib*, this is because they are stored together with the binary modules. The binary modules were first, then a few versions ago the qore library implemented support for "user modules" which are modules written in Qore instead of C++. libqore includes the user modules, and they are stored in the same directory as the binary modules. I had assumed (read: was hoping) that this would be acceptable, but if not, then I can make the appropriate changes to the language and the packaging to package them under /usr/share/qore-modules instead and have two locations for qore modules depending on the module type.
+ qore-devel: no-documentation: all the READMEs, etc were provided with libqore. The development documentation is provided in devel-doc. I'm not sure what to do about this - maybe add a README?
+ qore-devel: no-manual-page-for-binary: I have not written man pages for these programs yet - I had assumed from the Fedora packaging guidelines that this was a "nice to have" but not an absolute must. I am planning on writing man pages for these but do not have them yet.
+ qore.src: unversioned-explicit-provides: as above
Plus:
I re-added these as follows: %build export CXXFLAGS="%{optflags}" %configure --disable-debug --disable-static make %{?_smp_mflags}
I had misunderstood a review comment from Christopher Meng and $RPM_OPT_FLAGS before - I hope the solution above is better and future-proof.
It will take me a while to update the source with the updated license info, after which I'll post the URLs to the updated revision 3 sources for the qore packages.
Thanks again for your time and the detailed help with the review process.
thanks, David