Re: Ursa Major (modules in buildroot) enablement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux