9 a.m.
$ 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.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
9:03 a.m.
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
9:09 a.m.
>>>> "SO" == Stanislav Ochotnicky
<sochotnicky(a)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<
9:14 a.m.
On 08/22/2012 09:09 AM, Jason L Tibbitts III wrote:
>>>>> "SO" == Stanislav Ochotnicky
<sochotnicky(a)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
9:27 a.m.
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(a)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
9:38 a.m.
>>>> "RD" == Rex Dieter
<rdieter(a)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<
4264
days inactive
4264
days old
packaging@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Jason L Tibbitts III -
Ralf Corsepius -
Rex Dieter -
Stanislav Ochotnicky