https://bugzilla.redhat.com/show_bug.cgi?id=1111691 --- Comment #13 from David Nichols <david@xxxxxxxx> --- (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: > > * https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags 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 -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review