[Bug 1658199] Review Request: netatalk - Open Source Apple Filing
Protocol(AFP) File Server
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1658199
--- Comment #27 from Scott Talbert <swt(a)techie.net> ---
(In reply to Andrew Bauer from comment #26)
> From my el7 server:
>
> > $ type ldconfig
> > ldconfig is /usr/sbin/ldconfig
>
> Performing a yum whatprovides /usr/sbin/ldconfig, shows the binary is part
> of the glibc package:
Ah, right. EL7 still uses yum, I do see the provide for /usr/sbin/ldconfig
with yum on EL7. However it doesn't show up for dnf on EL7.
> For el7, the path to ldconfig is correct.
>
> For fedora, what we care is about is ensuring that the %ldconfig macro is
> not defined at all, which is the case with the last change I made.
>
> The netatalk package currently installs on two machines I have running, one
> f28 the other f29.
> It installs on my machines because I do in fact have /usr/sbin/ldconfig
> present on the filesystem, on both of these machines. It is a mystery why it
> is present, but that is the reason why I can install the package and you
> cannot.
Well, I looked on my systems - it turns out that /usr/sbin/ldconfig is there as
well. It appears that it's a hard link between /sbin/ldconfig. The presence
or absence of /usr/sbin/ldconfig isn't what's causing the installation failure,
though. It's dnf not seeing a Provide for /usr/sbin/ldconfig. Are you perhaps
installing directly with rpm or something?
> Unless we can find some documentation stating definitively whether or not
> rhel 8 will require calling ldconfig, I'd rather just leave the macro as it
> is set currently.
Well, rhel 8 will certainly be using dnf so I think you should probably use the
/sbin/ldconfig path that it will find. That's what the packaging guidelines
use, anyway.
--
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
5 years, 2 months
[Bug 1658199] Review Request: netatalk - Open Source Apple Filing
Protocol(AFP) File Server
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1658199
--- Comment #26 from Andrew Bauer <zonexpertconsulting(a)outlook.com> ---
From my el7 server:
> $ type ldconfig
> ldconfig is /usr/sbin/ldconfig
Performing a yum whatprovides /usr/sbin/ldconfig, shows the binary is part of
the glibc package:
>$ yum whatprovides /usr/sbin/ldconfig
>Loaded plugins: fastestmirror, langpacks
>Loading mirror speeds from cached hostfile
> * base: mirror.tzulo.com
> * epel: d2lzkl7pfhq30w.cloudfront.net
> * extras: mirror.steadfastnet.com
> * rpmfusion-free-updates: muug.ca
> * rpmfusion-nonfree-updates: muug.ca
> * updates: mirror.tzulo.com
>glibc-2.17-260.el7_6.3.x86_64 : The GNU libc libraries
>Repo : @updates
>Matched from:
>Filename : /usr/sbin/ldconfig
For el7, the path to ldconfig is correct.
For fedora, what we care is about is ensuring that the %ldconfig macro is not
defined at all, which is the case with the last change I made.
The netatalk package currently installs on two machines I have running, one f28
the other f29.
It installs on my machines because I do in fact have /usr/sbin/ldconfig present
on the filesystem, on both of these machines. It is a mystery why it is
present, but that is the reason why I can install the package and you cannot.
Unless we can find some documentation stating definitively whether or not rhel
8 will require calling ldconfig, I'd rather just leave the macro as it is set
currently.
--
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
5 years, 2 months
[Bug 1658199] Review Request: netatalk - Open Source Apple Filing
Protocol(AFP) File Server
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1658199
--- Comment #25 from Scott Talbert <swt(a)techie.net> ---
> # rhel need to call ldconfig
> %if 0%{?rhel}
> %global ldconfig /usr/sbin/ldconfig
> %endif
Actually, I think the problem is that the actual path is /sbin/ldconfig not
/usr/sbin/ldconfig. The file-based Provides seem to only work for the real
path, not symlinked ones. I don't know how you are able to install it onto
your system. Are you using dnf to install it?
Also, I think you could keep the rhel version check and do something like:
%if 0%{?rhel} && 0%{?rhel} <=7
--
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
5 years, 2 months