sysdig installs development libraries & headers by default. These are rarely used unless people write their own sysdig-like integration or tools, but take up ~35 MB due to static linking. For a regular sysdig installation they can be made optional with USE="-libs" with no loss of functionality. Reproducible: Always Steps to Reproduce: 1. install sysdig 2. lots of rarely used development stuff is installed
We don't normally make libs/headers optional in Gentoo.
(In reply to Mike Gilbert from comment #1) > We don't normally make libs/headers optional in Gentoo. These libs are "usable" in the technical sense, but kind of unversioned since they are only static. Upstream are working on allowing them to be shared libs with proper soname but that's some time away. Their main purpose is to be linked into the main executables. I'm not aware of a single project actually using them (they were split of the executable for purely political & licensing reasons). I will gladly revisit this when the libs are a separate ebuild/dependency of the main program and installed as properly versioned shared libs. Until them I'd like to get them out of the way by default.
(In reply to Holger Hoffstätte from comment #2) > I will gladly revisit this when the libs are a separate ebuild/dependency of > the main program and installed as properly versioned shared libs. Until them > I'd like to get them out of the way by default. Question. If it doesn't make sense to install them as a separate ebuild due to the fact that they aren't properly-versioned shared libraries, why would it make sense to install them in the same ebuild either? Maybe we should unconditionally delete them, in that case?
(In reply to Eli Schwartz from comment #3) > (In reply to Holger Hoffstätte from comment #2) > > I will gladly revisit this when the libs are a separate ebuild/dependency of > > the main program and installed as properly versioned shared libs. Until them > > I'd like to get them out of the way by default. > > > Question. If it doesn't make sense to install them as a separate ebuild due > to the fact that they aren't properly-versioned shared libraries, why would > it make sense to install them in the same ebuild either? > > Maybe we should unconditionally delete them, in that case? My thoughts exactly! Previously they were installed only by accident (since that's what the falcosecurity/libs cmake build does by default). I only added the USE flag to be a bit more backwards-compatible. Also searched through ::gentoo for users of USE=libs but only found bittorrent-core. So..unless someone objects I can gladly unconditionally delete them and remove the libs flag. Works for me!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5ce92c88c01d4559ef83d7573091d19377e06535 commit 5ce92c88c01d4559ef83d7573091d19377e06535 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-08-09 09:30:03 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-08-20 00:48:00 +0000 dev-debug/sysdig: revbump for libs-0.17.3, do not install headers/libs A few fixes since libs-0.17.2. Building with LTO now works as well. Do not install development headers/libs due to many usability problems. Clean up some dependency QA issues. Closes: https://bugs.gentoo.org/938187 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> dev-debug/sysdig/Manifest | 1 + dev-debug/sysdig/sysdig-0.38.1-r1.ebuild | 131 +++++++++++++++++++++++++++++++ 2 files changed, 132 insertions(+)
