Bug 1531546 - glibc: Remove sln
Summary: glibc: Remove sln
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1536349
TreeView+ depends on / blocked
 
Reported: 2018-01-05 13:18 UTC by Florian Weimer
Modified: 2018-09-05 09:32 UTC (History)
15 users (show)

Fixed In Version: glibc-2.26.9000-35.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-05 13:38:24 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1625584 0 unspecified NEW redhat-lsb: %triggerpostun uses /sbin/sln, which no longer exists 2021-04-29 16:51:02 UTC

Internal Links: 1625584

Description Florian Weimer 2018-01-05 13:18:06 UTC
The sln program is no longer useful, so we will not ship it anymore.

Comment 1 Kai Engert (:kaie) (inactive account) 2018-01-19 11:41:05 UTC
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?

Comment 2 Florian Weimer 2018-01-19 11:51:54 UTC
(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.

Comment 3 Tuomo Soini 2018-01-19 12:24:03 UTC
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.

Comment 4 Carlos O'Donell 2018-01-19 21:57:16 UTC
(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?

Comment 5 Kai Engert (:kaie) (inactive account) 2018-01-22 11:37:36 UTC
Carlos, thanks for the suggestion, filed as bug 1537070.

Comment 6 Kamil Dudka 2018-01-22 13:41:51 UTC
(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.

Comment 8 Colin Walters 2018-02-16 22:06:21 UTC
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

Comment 9 Tuomo Soini 2018-02-17 08:48:58 UTC
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.

Comment 10 Colin Walters 2018-02-17 16:00:25 UTC
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.

Comment 11 Colin Walters 2018-02-17 16:04:02 UTC
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

Comment 12 Klaas Demter 2018-09-03 14:32:48 UTC
There is still something in the package that references sln, see comment in https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb2271134d

Comment 13 Florian Weimer 2018-09-03 14:40:17 UTC
(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.

Comment 14 Klaas Demter 2018-09-03 15:14:19 UTC
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?

Comment 15 Florian Weimer 2018-09-05 09:31:36 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.