Hi
On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani manisandro@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.