Questions
Questions
Posted Feb 6, 2025 10:25 UTC (Thu) by callegar (guest, #16148)Parent article: Vendoring Go packages by default in Fedora
While a lot of the discussion appears to be focused on the advantages/disadvantages of vendoring or of the "go" model vs the traditional distribution model, and what is better, maybe there should be other factors to consider once a distribution decides to adopt a model different from its traditional one, related to the expectations of the distro users.
- should packages that use vendoring be immediately recognizable as such?
- should packages that bundle dependencies in, and thus somehow refuse the traditional distribution dependency management be allowed to have dependencies? Should only a very restricted set of dependencies be allowed? Should other packages be allowed to depend on them?
- should distros have the burden to update the bundled dependencies when there is an issue with them even if that breaks the alignment with the upstream developer?
Based on the answers to these questions, there could be a simplified/different packaging for the code that uses bundling and vendoring going side to side to the traditional distro one. Which is maybe, what is already done with flatpaks: users immediately recognize that it is a different type of packaging with a different type of dependency management. So maybe the point is just to extend flatpaks to make them more similar to regular packages wrt isolation or lack thereof and to fully support CLI.
- should packages that use vendoring be immediately recognizable as such?
- should packages that bundle dependencies in, and thus somehow refuse the traditional distribution dependency management be allowed to have dependencies? Should only a very restricted set of dependencies be allowed? Should other packages be allowed to depend on them?
- should distros have the burden to update the bundled dependencies when there is an issue with them even if that breaks the alignment with the upstream developer?
Based on the answers to these questions, there could be a simplified/different packaging for the code that uses bundling and vendoring going side to side to the traditional distro one. Which is maybe, what is already done with flatpaks: users immediately recognize that it is a different type of packaging with a different type of dependency management. So maybe the point is just to extend flatpaks to make them more similar to regular packages wrt isolation or lack thereof and to fully support CLI.