$ repoquery --provides bind-dyndb-ldap.x86_64 2>/dev/null bind-dyndb-ldap = 1.1.0-0.14.rc1.fc17 bind-dyndb-ldap(x86-64) = 1.1.0-0.14.rc1.fc17 ldap.so()(64bit) <-------???
$ repoquery --list bind-dyndb-ldap.x86_64 2>/dev/null /usr/lib64/bind/ldap.so ...
I came upon this when runnning fedora-review on this package. Now I am wondering: Is this a packaging problem in bind-dyndb-ldap (i.e. it has provides for private shared unversioned library) or is it OK? The so file is outside ldpath so that's not an issue.
On 08/22/2012 09:00 AM, Stanislav Ochotnicky wrote:
$ repoquery --provides bind-dyndb-ldap.x86_64 2>/dev/null bind-dyndb-ldap = 1.1.0-0.14.rc1.fc17 bind-dyndb-ldap(x86-64) = 1.1.0-0.14.rc1.fc17 ldap.so()(64bit) <-------???
$ repoquery --list bind-dyndb-ldap.x86_64 2>/dev/null /usr/lib64/bind/ldap.so ...
I came upon this when runnning fedora-review on this package. Now I am wondering: Is this a packaging problem in bind-dyndb-ldap (i.e. it has provides for private shared unversioned library) or is it OK? The so file is outside ldpath so that's not an issue.
IMO, it's ok.
-- rex
"SO" == Stanislav Ochotnicky sochotnicky@redhat.com writes:
SO> I came upon this when runnning fedora-review on this package. Now I SO> am wondering: Is this a packaging problem in bind-dyndb-ldap SO> (i.e. it has provides for private shared unversioned library) or is SO> it OK? The so file is outside ldpath so that's not an issue.
I would definitely filter it if building for a release new enough to have the filtering setup that can handle archful packages (which at this point is any Fedora release).
These still haven't made it into any guidelines, though. At least there's now some documentation at http://rpm.org/wiki/PackagerDocs/DependencyGenerator
- J<
On 08/22/2012 09:09 AM, Jason L Tibbitts III wrote:
"SO" == Stanislav Ochotnicky sochotnicky@redhat.com writes:
SO> I came upon this when runnning fedora-review on this package. Now I SO> am wondering: Is this a packaging problem in bind-dyndb-ldap SO> (i.e. it has provides for private shared unversioned library) or is SO> it OK? The so file is outside ldpath so that's not an issue.
I would definitely filter it
Or get rpm to autoprov only on ldpath'd items...
-- rex
On 08/22/2012 04:14 PM, Rex Dieter wrote:
On 08/22/2012 09:09 AM, Jason L Tibbitts III wrote:
> "SO" == Stanislav Ochotnicky sochotnicky@redhat.com writes:
SO> I came upon this when runnning fedora-review on this package. Now I SO> am wondering: Is this a packaging problem in bind-dyndb-ldap SO> (i.e. it has provides for private shared unversioned library) or is SO> it OK? The so file is outside ldpath so that's not an issue.
I would definitely filter it
So would I.
Such provides are supposed to be referring to *.sos in ldd's search-path. Not filtering would just fillup the rpmdb with bogus contents and are possible causes for rpm-dep conflicts.
IIRC, such conflicts once had hit some perl modules. For them, filtering meanwhile is considered mandatory.
Or get rpm to autoprov only on ldpath'd items...
Does ldd pickup non-"lib" prefixed *.sos?
Ralf
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> Or get rpm to autoprov only on ldpath'd items...
Now that's just crazy talk!
It's a little more complicated than that, for a couple of reasons: ldpath can change (just drop a file into /etc/ld.so.conf.d), different types of dependency generators certainly want to look outside of ldpath (e.g. perl) and the rpm macros, while much nicer than what we used to have (i.e. nothing), are purely exclusionary so we can't set distro defaults to which packages could add if necessary.
- J<
packaging@lists.fedoraproject.org