On Mon, 20 Dec 2021 at 10:16, Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Sat, Dec 18, 2021, at 5:06 PM, Fabio Valentini wrote: > > > > Sure, I saw that ticket. But I fail to see how this is this a "new problem". > > If you use, for example, some shiny, new features that are only going > > to be in GCC 12 or LLVM 14, > > There's a *big* difference between Go and C/C++/Rust though, which is that the version of the Go compiler you use at build time becomes the version of the Go *runtime* statically linked into your binary, with implications for things like GC performance. > > Go's 6-month cadence is also much faster than C/C++ (though also much slower than Rust's, but the Rust 6 week releases are also smaller, and anyways generally the ecosystem is OK with "older" Rust compilers). Also relating to the release cycle, Go releases tend to add new features that parts of the ecosystem adapt relatively quickly. That seems likely to continue with 1.18 and the early generics. > > > you'd be out of luck on stable Fedora > > branches, as well. > > Not quite; one doesn't need to use the single Go compiler version in RPM form from Fedora except currently when shipping software built as Fedora RPMs. (I know this was implicit in this discussion, but it's worth noting because people can and do get the Go compiler from e.g. upstream on Fedora systems too to build and ship software outside of the Fedora package collection itself) > > That said, I don't quite understand why it's so complex to use modularity as part of building non-modular RPMs. (But I know this was extensively discussed, I didn't follow it really) > It seems like it's more about maintaining multiple builds of the compiler/runtime. > The following is based on the lessons learned from EPEL-8. Koji does not really know much about modules or even RPMs beyond a src.rpm. So when koji is putting together a build root it will pull in things which best satisfy a spec files requires. Case 1: Module A: - golang-17 - golang-foo-3.4-<fill_in_hash> Module B: - golang-18 - golang-foo-3.4<fill_in_hash_bigger than ModuleA's> In this case, you could define a spec which requires golang-17 but koji's dep resolver pulls in golang-foo- from Module B for non-modular packages. This breaks the build. Case 2: Module A : - golang-17 - golang-foo-3.4-<fill_in_hash> Module B: - golang-18 - golang-foo-3.4<fill_in_hash_smaller than ModuleA's> or - golang-foo-3.3 <because it works better with 18> Koji's dep resolver in this case will then pull in Module A's golang-foo for any 'non-modular' package which required golang-foo. You can configure koji to do a slightly different depsolving using dnf versus the koji algorithms, which fix things in that only default modules may get enabled in mock. [However may is a strong word.. it sometimes does not.] The fixes to this are: a) use a tool like grobisplitter which breaks out all modules into separate repositories versus 'virtual repositories'. This allows koji and mock better ability to sort out what is the right package to put into the buildroot. b) use a script program like ursa major which basically hardwires in MBS determinations. This works for EL8/EL9 because the changes in modules has to go through a lot of internal checklists and such to make sure the script is updated and doesn't break in builds. It doesn't work that well in Fedora unless we put in similar 'please mark this package as to be used for this and get a PR signoff' [or someone writes and maintains a tool to do this which they did in MBS...] c) everything which uses a module, requires to be a module. Then MBS does all this determination and tells koji -> I don't care what you think, tag in Module-B's golang-foobar for this build. d) someone replaces koji with a build system which knows about MBS and other meta-tools. > It's interesting to note that in CentOS Stream 8, go-toolset is modularized, but that's not true in CentOS Stream 9. > > Also related to this, it's worth looking at what others do; e.g. NixOS seems to maintain a few versions of Go: https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/go > But they only have one Rust version. Although there are a ton of derivations for gcc and llvm, I suspect only a few are used. > > It looks like Debian ships package+versions, e.g. `golang` is 1.17, and there's `golang-1.15` in unstable. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
