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