> Consider the Go case: we know that most Go packages will be statically > linked (issues with that are a different topic), so we know they will > work fine once built. However, if the application upstream cannot > build with the latest "stable" version because of > backwards-incompatible changes, it seems to me that it's perfectly > reasonable to allow them to use a slightly older Go compiler from a > module stream. Strictly speaking, this is no different from offering > an SCL or a compat-* package of the compiler, except that having it as > a module means that its executables and other tools will be in > standard locations, so the build process doesn't need to be patched to > locate them elsewhere. <snip> > > What we are doing is providing additional tools. If you do not wish to > use them to build your packages, don't! That's fine. For others, it's > a matter of putting a price on their time: is it worth spending an > extra two months hacking on a package in the name of ideological > purity, or is that two months better spent doing other work? The > Fedora of a few years ago would have *required* the former approach. > Fedora today is more welcoming.
If you take this compromise to an extreme then let's solve the Java problem (or <insert similar stack here>) and grant an internet access to builds. This way we can use vanilla maven/gradle/ivy to fetch dependencies at build time and make sure that we can upgrade to the latest versions of any leaf package. For the Go case (and we can include Rust too) it is indeed very likely that, because the model is almost exclusively static linking, a leaf package will force the creation of dozens of devel packages only for the sake of BuildRequir'ing them. What about changing guidelines to allow such packages to have multiple SourceX archives and list their dependencies as bundled(xxx) in the final RPM? I would argue that Go and Rust leaf packages should already advertise their dependencies as bundled because of their very nature. This way adding a Go or Rust application could lessen the burden on package maintainers and still provide the metadata needed to keep track of what bundles what when an update is needed (CVE or other). Ideally helped with tools to avoid doing everything by hand... Again, I'm part of neither Java, Go or Rust SIGs and don't have time to follow modules closely. Apologies if that has already been brought up in the past. And I'm pretty sure that would hardly be a lead for NodeJS applications but I'm far less familiar with the latter. Dridi _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
