Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#56009 - [glibc] No need to ship sln binary
Attached to Project:
Arch Linux
Opened by Emil (xexaxo) - Monday, 16 October 2017, 10:26 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Tuesday, 28 November 2017, 16:43 GMT
Opened by Emil (xexaxo) - Monday, 16 October 2017, 10:26 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Tuesday, 28 November 2017, 16:43 GMT
|
DetailsDescription:
The package contains a neutered version of ln -> sln, which has everything statically linked in. The idea behind it is great - to be used when the dynamic linker does not work. At the same time: /sbin/init aka systemd relies on the linker working. So sln caters for something that cannot happen. AFACIT there are no programs/scripts that use the program, but we could use a symlink to ln just in case. Additional info: * package version - 2.26-5 |
This task depends upon
Closed by Bartłomiej Piotrowski (Barthalion)
Tuesday, 28 November 2017, 16:43 GMT
Reason for closing: Won't fix
Tuesday, 28 November 2017, 16:43 GMT
Reason for closing: Won't fix
If you remove /lib64, you'll break your system and there's one of two ways to fix it: sln, or invoke the linker directly to execute ln.
What's the goal of this request? Save 600k disk space?
On the question of why - I have a script which flags programs that are statically linked.
I believe that's one of the rules Arch developers have been sticking to.
If you think it's a bad idea and/or brings no benefit do close this.