----- Original Message -----
From: "Stephen Gallagher" <sgallagh(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, October 17, 2019 2:41:28 AM
Subject: Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
> > (And how would restricting default streams to only be able to depend on
> > default streams change things?)
>
> It would solve the version conflicts issue, so it makes a lot of sense, but
> at that point, why not require the default versions to just be non-modular
> instead? The main argument for using default streams was that they can
> depend on non-default streams of other modules. So if we disallow this
> (which I think makes sense), we may as well disallow default streams
> entirely and simplify things for everyone. (We would just need a short-term
> workaround for the default streams that exist now. The problem would be
> gone
> in the long run.)
>
There's still a case that you haven't considered, which is things that
work at runtime as a default but cannot *build* against the default
set of packages. For example, we might have packages whose buildsystem
still relies on Python 2 (WAF?) but doesn't require it at runtime.
There might be packages that haven't yet migrated to a new,
backwards-incompatible change to Docbook for generating documentation.
Or packages that only build properly with a newer version of golang
than shipped in that release, or any of a thousand other examples that
are easily solved by build-time-only content and dependencies in
module streams.
In current context(1.X) package that doesn't build with new version of Go has usually
serious issue(s) on the side of the package/upstream. Fortunately this is really uncommon
in my experience(even for packages/upstreams that fear/think that they will break with
newer version of Go).
Also there are yet other packages (such as in the Go and Rust
ecosystems) that could simply be built once on Rawhide with the latest
compiler and shipped to each of the other releases without needing a
rebuild because they are statically linked. Modules allow this, basic
RPMs not so much.
For Go this is oversimplification and common misconception(go built binaries are not
uncommonly dynamically linked in the "C/ELF" sense(glibc,...) and statically
linked in Go sense). It might work for some selected(maybe even most) Go based packages,
but not always(new glibc,...) and not universally.
JC
>
> So even if we eliminate the version conflicts issue by restricting
> what comprises a default stream, there are other benefits to module
> default streams.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
>