Hi
On Tue, Feb 8, 2022 at 12:45 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl> wrote:
>
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
>
> Since mingw-*.spec are very repetitive and cumbersome to modify (each
> mingw32, mingw64, ucrt package has to be defined manually, and this is
> tedious and error-prone), a custom MinGW/Fedora tool or solution will
> be proposed. In the meantime, packages can be modified to add manually
> the new target.
I think this is an important point. If this is to be done manually,
the transition will take forever and will consume a lot of maintainer
resources. I would very much encourage you do first develop macroification
to make the new subpackages easy to add. And once that is done, do spec
file munging semi-automatically, like it was done when we were renaming
python2 subpackages. (This was similar, because we needed to add a new
%package
section and related sections.) Once the whole thing is ready, use a
provenpackager
to update and build all packages. In my exprience, it is also important to
ask maintainers to *not* do manual conversions, because if you add
automatization
later on, manually converted packages end up being a bit different and in
the end
are more trouble than running the automatic converted over a few additional
files.
If that'd be helpful, I can dig up the scripts for python2. I'd be happy
to help
with building scripts to do the conversion here, though I know almost nil
about
mingw.
So far, what I built is a custom python/jinja script to generate the spec,
here is the code and example with mingw-zlib:
https://gitlab.com/-/snippets/2243878
Ideally, we would use built-in RPM template facilities, but that may take a
while:
https://github.com/rpm-software-management/rpm/issues/1472.
It will be hard to automate the translation from existing spec to a
template form, but I can eventually look at it.
Adding ucrt64 packages is still optional, and can be done manually anyway.
Templating is optional too, obviously.
Also I don't know what are Daniel Berrange plans to have native and cross
packages built from the same spec. We might end up with a very different
solution then.
--
Marc-André Lureau