Hi On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani <manisan...@gmail.com> wrote: > > > > Interesting question, it really depends on our users I imagine. > > > > Since Windows recommends ucrt since Windows 10 (2015) and you can ship > > UCRT for earlier versions up to Vista, there are very few reasons you > > would want to keep msvcrt. Notably, wine may need msvcrt binaries. > > However, if this is the only case, we probably don't want to keep > > maintaining and distributing all the msvcrt binaries with Fedora. > > > > My recommendation going forward (past f37 and ucrt toolchain > > introduction probably, unless we all agree?) would be to remove > > mingw32/64 libraries, but keep the various toolchains. This way, users > > who still want to target msvcrt can rebuild their dependencies > > themself relatively easily. > > This is what I was kinda also thinking about. The one thing that scares > me TBH is having to go through rename-rereview of all mingw -> ucrt > packages. I wonder if one could handle it like
Why renaming? what I propose is to add ucrt64-* libraries. For example, we have mingw32-zlib & mingw64-zlib today. We would have to add a third ucrt64-zlib. It's tedious, but we don't have to do it all in one go, we can add it over time. And with the simple template system I propose (until RPM provides something) it is easier to adapt, it avoids having to repeat things. > > - ask FESCO to rename without re-rereview all mingw32/64-* packages to > win32/64-* (or whatever generic windows prefix), leaving the runtime out > of the package name > - when the time comes, change the runtime and just recompile the entire > mingw/win package set That won't work. One reason you need a transition period is also because ucrt may introduce regressions in your package that you may have to work on.. I have fixed a few ucrt-related issues in glib (among others https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449) > > So not even ever offering mingw and ucrt side-by-side, except perhaps > for the selected core toolchain packages to allow users to build their > own packages if they wish > > > > > Sometime I even think more radically, and think that Fedora should > > stop maintaining & distributing all the mingw libraries. Instead, work > > with the msys2 project, to have a common place to maintain those. I am > > not sure what shape this would take, but I am sure this could be very > > fruitful, especially if other distros take the same approach > > (debian/ubuntu/arch etc). > > I guess this would add the challange of keeping the packages in sync > with the corresponding native version (which is already quite a > challenge inside the distro actually). Fedora would no longer ship any library or windows binaries (almost), only the cross toolchain. You would simply run "msys2-pacman -S foopkg" and get either the same package distributed for Windows installed somehow on your distro (perhaps even under $HOME), or a side msys2 project could cross-build them package for your target linux distro (if that's necessary, but I think we could eventually get the same windows packages). For the vast majority of packages, that approach should work. The other approach is to simply vendor and cross-build your dependencies with your project (like meson wrap, rust etc are doing). The required bits are only the cross-toolchains then. _______________________________________________ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-le...@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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
