Le dimanche 16 février 2025 à 06:18 -0600, rhys a écrit : > > If the upstream intends to distribute it with a tarball, that's the > "golden" package that downstream should base code upon. > > Going around that decision means subjecting all of Debian to code > pulled from their repo outside of their distribution process.
I don't understand: it never was about packaging a random git commit. Upstream works on code in a preferred form, and tags a definite commit as being version 3.14159. This gets in some tarballs already in some cases (github comes to mind) ; call that source-level-zero. >From this upstream runs some tool (generally triggered by their tagging) ; often some autotools, 'dune' on the package which started this thread, but rust/js/ruby/whatever also have their own. This tool turns the git commit tree into some pre-compiled tree, put into another tarball. Call this source-level-one. The point I made about the elpi package is that we want to ship source- zero, as that's what upstream works on. This is in line with Debian shipping autotools-based packages but re-running the autotools before they run configure again. > How much function is lost as a result is nothing compared to the > instability of packages that can result from distributing code that > was not meant for distribution. Well, "use what upstream publishes" sounds nice until you look at the landscape : - many Python upstreams use pypi and consider that their pypi package is what they publish ; - many JavaScript upstreams use npm and consider that their npm package is what they publish ; - many Rust upstream use cargo and consider that their cargo package is what they publish ; - many OCaml upstreams use opam and consider that their opam package is what they publish ; - many Coq upstreams use a sub-distribution of opam (the Coq Platform) and consider this is what they publish ; - etc. There is a huge confusion in many upstream's heads that putting their software on people's computers is what "distributing" means. The fact that their software is only semi-coherent with the system (only within a certain programming language boundary) is a problem. Debian is a whole-system distribution ; we make sure software works in a coherent system-wide way, and basing our packages on code which has already been pre-package for a subpar distribution (language-limited) isn't a good option. Cheers, J.Puydt
