On Mon, Jan 20, 2025 at 8:02 AM Mikel Olasagasti <mikel@xxxxxxxxxxxxxxx> wrote: > > Hi, > > Go-SIG has raised a ticket with FESCo [1] to propose a significant > shift in Fedora's packaging approach for Go dependencies: moving to > vendoring/bundling by default. This would represent a major departure > from our current guidelines [2]. > > Given the potential impact, it was suggested that we bring this topic > to the devel-list for broader input and an open discussion. > > The rationale for this proposal stems from the increasing challenges > in maintaining Go dependencies under the current model, including > issues with timely reviews, dependency management, and the impact of > some "core" orphaned packages. Allowing vendoring by default could > help alleviate these bottlenecks and improve the stability of Go-based > packages in Fedora. > > If this proposal gains consensus, we could aim to implement the change > as part of Fedora 43, with the development phase used for migration > and retiring packages that may no longer fit within the updated > framework. > > On a related note, I recently highlighted how the introduction of > Golang 1.24 has caused significant breakage in over 200 packages [3], > an issue that underscores the urgency of addressing these challenges. > > We invite all Fedora contributors, maintainers, and stakeholders to > share their perspectives, concerns, and suggestions on this topic. Thank you for opening this discussion! I do understand the problems that the Go SIG is facing here, and I've had the same experience. I used to need to poke golang-* library maintainers to update to a new git snapshot of libraries just so I could ship a bugfix update for syncthing. (Tagged releases? Apparently blasphemy in the Go world, though not as bad as it used to be, I hear.) This got bad to the point where almost every upstream release added new dependencies, bumped others, and removed others, which was when I just gave up and started building against the vendored sources (which are actually included in the source release tarballs published by the upstream project). This reduced the number of bugs caused by building against versions of libraries that don't match what the upstream project builds / tests against, and allowed shipping security and bugfix updates faster. [/preface] That said, reading other posts in this thread, I just don't think this is a good model for *all* "non-ELF" languages, and it shouldn't serve as a precedent. The Go ecosystem is a little bit special, in that there is no package manager in the real sense - dependencies are basically just pointers at "<git repository><tag / commit>". Mapping this "scheme" (or lack thereof) to RPM packages has proven to be difficult. Speaking for the Rust package ecosystem, we just don't have many of the same problems outlined here for Go. There is one central registry for libraries (crates.io), with a flat (for now) namespace that we can map 1:1 to RPM package names. Additionally, it is almost trivially easy to ship multiple versions of the same library in parallel-installable RPMs, because the build tooling already natively namespaces dependencies by both name *and* version in its expected directory layout - so there is no "dependency hell", like in Go. I also don't understand the argument of "bundling would let us solve 200 broken packages caused by Go compiler changes faster". If the libraries fail to compile in standalone packages, then they should fail to compile in any Go application that vendors them as dependencies too, right? So it just moves and multiplies the problem (into all applications that vendor this dependency). Also, in my experience, patching vendored dependencies downstream is *really really annoying*, at least in the Rust world - because the tools are just not made to handle the case of "vendor this dependency, but apply this unverified patch on top of it - trust me, it's fine". So if you need to apply any patch to a Rust library that is vendored ... well, good luck. It *is* possible, with workarounds (disabling checksum checks, etc.) but it's very gnarly. On the other hand, applying a security update for a packaged Rust crate is basically trivial. This requires only *one* package to be changed, and applications that statically link the library can be rebuilt against the new version without requiring any spec changes. (Before somebody responds with "but konflux!": No, konflux would not make the Rust workflow significantly easier. If you think the file format of the "shippable unit" or the build system behind the scenes are the hard part, then you don't understand the problem.) Another downside of using vendored dependencies (and it's a pretty big downside, IMO) is that - at least for Rust - it's not possible to run the test suites of those libraries - for one, because test-only dependencies of dependencies aren't included in vendored sources. Running tests for Rust crates (where possible) has proven very valuable to find architecture-specific bugs in libraries, LLVM bugs, Rust compiler bugs, etc. This would not be possible (and hence, would not happen) in the "vendored dependencies" world. I don't know how valuable running tests for Go libraries is in general, but in the past, when I used to maintain packages for Go libraries myself, running tests has revealed architecture-specific issues and race conditions on more than one occasion. Fabio -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
