News for hackers. Stuff that matters.
Re:The abysmal state of GNU/Linux and a case against shared ... by singron on Monday October 14, 2024 @07:13PM (#41843194)
The build time is pretty significant actually. E.g. NixOS takes this to the extreme and always rebuilds packages if their dependencies change. It can take days to rebuild affected packages, and you typically can't easily update in the meantime. This is worse if the rebuild breaks something since someone will have to fix or revert that before it can succeed.

For non-security updates, they can do the rebuild in a branch (staging) so it's non-blocking, but you will feel the pain on a security update.

In practice, users will apply a config mitigation if available or "graft" executables against an updated lib using system.replaceDependencies, which basically search and replaced the built artifacts to use a different file path.

Re:The abysmal state of GNU/Linux and a case against shared ... by Arnavion on Monday October 14, 2024 @07:18PM (#41843230)
True. I'm involved in Alpine, postmarketOS and OpenSUSE packaging and I've seen builders of the first two become noticeably slow on mass rebuilds. OpenSUSE tends to be fine, but it has a lot of builders so that's probably why.
Re:The abysmal state of GNU/Linux and a case against shared ... by JackSlateur on Tuesday October 15, 2024 @05:23AM (#41846663)
It shall be noted that there is no need to recompile everything, when a library's patched: you only need to relink the executables and rebuild the packages

Still, this requires a somewhat bigger infrastructure