https://bugzilla.redhat.com/show_bug.cgi?id=1111691
--- Comment #13 from David Nichols <david(a)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
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