Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 14:19 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ... by LtWorf
Parent article: Vendoring Go packages by default in Fedora

Unfortunately, distro policies mean that Debian (for one) will change your ">= x.y.z" to "=a.b.c" where a < x (because that's the version they ship), remove your checks that fail compilation if I try to use anything with major < x, and then consider it a bug in your code that you don't work with the version of the library that they packaged in their stable distro.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 16:52 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

Then you WONTFIX it and redirect all bug reports to the Debian bug tracker. Their code change, their bug.

This isn't even rude. Debian explicitly encourages users to report bugs to Debian and not to upstreams.

Distros lacking power

Posted Jan 30, 2025 12:32 UTC (Thu) by farnz (subscriber, #17727) [Link]

Yep - but that then leads to the original complaint, of the distros not having the power to get upstream to care about stable ABIs and a solid dependency base. Why should I care, if the distro will handle it all for me internally, and do all that hard work for me?

And that's the real point - a stable ABI (in any language) involves a lot of hard work; the distros do this work for C programs (with re-education of significant upstreams), but aren't able + willing to do it for other languages. Further, because users already bypass the distro for programs that fit their needs, but don't have the right version packaged by their distro, the distro has very little power to make upstreams comply with their policies, since they have no leverage - users can and do go round the distro to deploy what they want.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 19:34 UTC (Wed) by dilinger (subscriber, #2867) [Link] (6 responses)

A lot of times this is done specifically because upstreams will bump dependency versions for no reason. It's one thing if you hit a bug in an older version of a library or are using some new API from that library, and therefore require a newer version of said library. It's quite another if you test out a new version of the library, discover that it works just fine, and bump the version build dependency as sort of an I've-tested-this-library-version update. I've seen this a lot with node and go applications in particular. Doing this kind of thing sets the assumption that version dependencies are arbitrary, and therefore distribution maintainers should be free to downgrade version dependencies.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 19:36 UTC (Wed) by bluca (subscriber, #118303) [Link]

Yeah this happens so many times it's not even funny. It's especially bad in Python, where tons of developers just pin their dependencies in requirements.txt to whatever they have on their Windows machine at that particular point in time. But yeah let's completely trust these developers with embedding OpenSSL in their network-facing app, I'm sure it will be just fine.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 23:00 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (4 responses)

They pin dependencies because that's what the bullshit corporate security scanners (snyk, sff scorecards) encourage them to do: to pin to a specific version and constantly change it and pin to the latest available version. Why not just not pin is a mystery.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 30, 2025 8:08 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

Pinning a given dependency usually means, at an absolute minimum, "I ran the unit tests and nothing is obviously broken with this version." In many cases, it also means "I ran the integration tests and nothing is obviously broken." For the bleeding edge version, that's probably about all you can expect from such pins.

For a stable release, it typically implies the same level of testing that you would expect for the release as a whole (hopefully a lot more than just running automated test suites). Obviously, any given distro's definition of "stable" will differ from the application developer's (unless the distro in question is e.g. Arch Linux), but frankly, that's the distro's problem to deal with.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 30, 2025 18:35 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

Except that in go there's a command in go itself to pin everything to latest. So what most people do is to have a bot that if there's a CVE calls that thing.

Effectively they're constantly using the latest version.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 30, 2025 22:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Dependabot on GitHub does only minimal upgrades. I also remember seeing a free version of it somewhere.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Feb 1, 2025 7:30 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

> Except that in go there's a command in go itself to pin everything to latest.

The intended use, to my understanding, is to repin everything to latest, run the automated tests, then commit if everything is green, else try to figure out what broke and why. It is not meant to be used in the automated fashion that you describe.

> Effectively they're constantly using the latest version.

The fact that some C developers write terrible code and complain that "the compiler" "broke" it, does not imply that all C developers are incapable of understanding the meaning of UB. By the same token, the fact that some Go or Rust developers do not care about backwards compatibility does not imply that all Go or Rust developers do not care.

Think about it: If this was *really* the intended use case, then pinning would not exist. It would just pull the latest every time, and you would never need to update your pins at all. Pinning, as a feature, only makes sense if you want to have some control over the version you are running.