Skip to main content

If #xz were a Go or Rust dependency, you wouldn’t have a single copy of xz library on your system, but many, #xzbackdoor hidden in every executable that uses it. Distros would have to rebuild all packages using that lib (not just the lib itself), which could take days or weeks, and users would have to update them all, downloading tens or hundreds of megabytes.

If you install binaries directly from vendors/devs, it’s even worse – you wouldn’t even know which ones are affected and you’d (1/3)

in reply to Jakub Jirutka πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦

be at the mercy of the devs to provide the update. Not a group of active maintainers behind the distro, but many individual devs, some of whom lack the time or motivation and sustainability. The same goes for Docker containers, Flatpak and similar!

This is called static linking or bundling. Instead of rebuilding and updating a single shared library, you have to rebuild and update every single thing that links/bundles it. In the case of static linking, you usually can’t even tell which (2/3)

reshared this

in reply to Jakub Jirutka πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦

libraries it’s linked with!

Now do you see the value of #Linux distros and dynamic linking? Please, stop this insane β€œsingle binary” mantra and work with distros, not against them.

If #rustlang wants to replace C, devs need to acknowledge this and start providing dynamically linkable libraries with stable ABI. (3/3)

reshared this

in reply to Jakub Jirutka πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦

#golang doesn’t even support any kind of shared libraries by design! Each Go binary bundles everything, including a rather large runtime. Linux distros have to rebuild all packages written in Go several times a year because of security vulnerabilities found in the Go runtime or stdlib. Go is a (not just) #security disaster.
in reply to Jakub Jirutka πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦

Yes! Reasonable release cycles is what protected #Debian from xz. Also extricating libraries "vendored" by upstream developers is crucial for security.
Unknown parent

Aleksandra Fedorova :fedora:


Upstreams should not choose versions of dependencies randomly in their own bubble.

To make deduplication of effort work, there should be awareness in every upstream that they need to align their choices with other upstreams.

The packaging and distributions ecosystem is where different upstreams meet and talk to each other about things like which versions to choose as a base for LTS branches, which versions to choose for shared libraries and so on.

@kravietz @Conan_Kudo @jakub

in reply to Aleksandra Fedorova :fedora:


And I may be need a separate statement:

I don't believe that every upstream developer must become a packaging expert.

I believe that packaging is a job on its own. For some projects you combine roles of developer, tester, doc writer and packager, for some you just can't. And then you ask for help.

But I believe that upstream developer should be aware that there are needs in software development beyond writing the code and pleasing the user.

@kravietz @Conan_Kudo @jakub

in reply to Aleksandra Fedorova :fedora:

@Aleksandra Fedorova :fedora: @ITwrx @Neal Gompa (ニール・ゴンパ) :fedora: @kravietz πŸ¦‡ @Jakub Jirutka πŸ‡ͺπŸ‡ΊπŸ‡ΊπŸ‡¦ and even for single person projects, having a packager in each main distribution that isn't the upstream developer is a big plus, as it provides a minimum of oversight and redundancy.

Not much, especially when said maintainer(s) are overworked and demoralized, but still better than nothing.

in reply to Elena ``of Valhalla''


Yes, that is an important point too.

When we say co-maintainer, we often implicitly assume that it should be an equally or comparably skilled person doing the same tasks.

And then we stop at a thought on how hard it is to find a duplicate.

While it doesn't have to be.

There is plenty of room for a developer to collaborate with a tester, or a packager or a build engineer, or a documentation writer.

It often can be healthier too.

@ITwrx @Conan_Kudo @kravietz @jakub

This website uses cookies to recognize revisiting and logged in users. You accept the usage of these cookies by continue browsing this website.