Bug 1531546

Please see bug 1536349. sln is used by the ca-certificates package to avoid a circular dependency. I'm sorry that there wasn't a dependency in place.

Unless there's a better solution to the problem, would it be possible to resurrect sln?

(In reply to Kai Engert (:kaie) from comment #1)
> Please see bug 1536349. sln is used by the ca-certificates package to avoid
> a circular dependency. I'm sorry that there wasn't a dependency in place.
> 
> Unless there's a better solution to the problem, would it be possible to
> resurrect sln?

The packages uses other programs from coreutils at build time and in the ca-legacy script (mkdir, mv, readlink), so you still need coreutils and can as well use ln instead of sln.

Adding dependeny to coreutils will cause cyclic dependency and failure in installing package again. It is enoug that coreutils always gets installed. But dependency would change install order causing breakage.

(In reply to Tuomo Soini from comment #3)
> Adding dependeny to coreutils will cause cyclic dependency and failure in
> installing package again. It is enoug that coreutils always gets installed.
> But dependency would change install order causing breakage.

The cycle would be via:

coreutils -> openssl-libs -> ca-certificates -> coreutils

To fix the cycle you would need a coreutils subpackage that doesn't need openssl-libs and that would allow you to bootstrap. Please take this requirement up with the coreutils team since they are the ones who might be able to solve the cycle.

I see there is a coreutils-single; I wonder if that was designed for breaking cycles like this?

Carlos, thanks for the suggestion, filed as bug 1537070.

(In reply to Carlos O'Donell from comment #4)
> I see there is a coreutils-single; I wonder if that was designed for
> breaking cycles like this?

I am not sure what the original motivation was (perhaps bug #1267979?) but coreutils-single indeed does not require openssl-libs.

https://src.fedoraproject.org/rpms/glibc/pull-request/3

Why does openssl-libs -> ca-certificates ?  I.e. why not


diff --git a/openssl.spec b/openssl.spec
index 880022e..48d2b78 100644
--- a/openssl.spec
+++ b/openssl.spec
@@ -73,6 +73,8 @@ BuildRequires: /usr/bin/pod2man
 BuildRequires: perl(Test::Harness), perl(Test::More), perl(Math::BigInt)
 BuildRequires: perl(Module::Load::Conditional)
 Requires: coreutils
+Requires: ca-certificates >= 2008-5
+Requires: crypto-policies
 Requires: %{name}-libs%{?_isa} = %{epoch}:%{version}-%{release}
 
 %description
@@ -84,8 +86,6 @@ protocols.
 %package libs
 Summary: A general purpose cryptography library with TLS implementation
 Group: System Environment/Libraries
-Requires: ca-certificates >= 2008-5
-Requires: crypto-policies
 # Needed obsoletes due to the base/lib subpackage split
 Obsoletes: openssl < 1:1.0.1-0.3.beta3
 Obsoletes: openssl-fips < 1:1.0.1e-28

Easy to answer. With your suggested change users of openssl-libs couldn't verify certificates.

So requirement is correct and can't be moved to base openssl.

Alternative would be to add those requires to all software using openssl-libs which is not a small thing to do.

It's almost certain that we'd have to explicitly list ca-certificates in more places; for example, the container base images, the fedora-atomic manifest, and I'm pretty surprised it's not in comps at all.

Actually why don't we just:
ln -sr /usr/bin/ln /usr/bin/sln
in glibc?  That's what is done here (albeit a hard rather than symlink): https://pagure.io/fedora-kickstarts/blob/e3c3cf3116f6751f717622d33553b32f432081b0/f/fedora-docker-base-minimal.ks#_21

There is still something in the package that references sln, see comment in https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb2271134d

(In reply to Klaas Demter from comment #12)
> There is still something in the package that references sln, see comment in
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb2271134d

Quoting from there:

  Running scriptlet: glibc-2.27-32.fc28.x86_64                              2/2
/var/tmp/rpm-tmp.FQWpDI: line 5: /sbin/sln: No such file or directory
  Verifying        : glibc-2.27-32.fc28.x86_64                              1/2

My understanding is that this could be any late (%posttrans?) scriptlet.  I don't think DNF or RPM logs this by default, so it's difficult to figure out what's going on.

You could try:

rpm -qa --scripts
rpm -qa --triggers

and narrow it down from there.

ah yeah, I forgot about the triggers :)

[root@notebook klaas]# rpm -q --triggeredby glibc
cronie-1.5.1-9.fc28.x86_64
redhat-lsb-4.1-44.fc28.x86_64
[root@notebook klaas]# rpm -q --triggers redhat-lsb
triggerpostun scriptlet (using /bin/sh) -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.x86_64 ]; then
  /usr/sbin/redhat_lsb_trigger.x86_64
fi

  /sbin/sln ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so || :


so that's actually in redhat-lsb, should this be a seperate bug?

(In reply to Klaas Demter from comment #14)
> ah yeah, I forgot about the triggers :)
> 
> [root@notebook klaas]# rpm -q --triggeredby glibc
> cronie-1.5.1-9.fc28.x86_64
> redhat-lsb-4.1-44.fc28.x86_64
> [root@notebook klaas]# rpm -q --triggers redhat-lsb
> triggerpostun scriptlet (using /bin/sh) -- glibc
> if [ -x /usr/sbin/redhat_lsb_trigger.x86_64 ]; then
>   /usr/sbin/redhat_lsb_trigger.x86_64
> fi
> 
>   /sbin/sln ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so || :
> 
> 
> so that's actually in redhat-lsb, should this be a seperate bug?

Thanks, I filed bug 1625584 for this matter.