On Tue, Feb 08, 2022 at 12:54:32PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Feb 08, 2022 at 02:13:34PM +0400, Marc-André Lureau wrote: > > 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. > Yes, I think you need to assume that this will not happen soon. > (If ever. I think that there are significant doubts whether this type > of templating is desirable.) > > > 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. > > Hmm, but wouldn't the goal be to provide ucrt64 everywhere where there are > existing mingw packages? If users are to transition to ucrt64, they would need > to be able to assume that they can do that without regressions. Yes, if we're going to add ucrt64 support then I think the expectations a would be for it to be added in all packages, in a reasonably timely manner. Doing everything in 1 release is likely unrealistic, but at the same time it isn't nice to let it drag out over an indefinite number of releases. As a historical reference, see when we added mingw64 support to the existing mingw32 packages: https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler That was a bit more complex as it was actuallly swapping out the toolchain, and rebuilding all existing mingw32 packages with the new mingww64 toolchain, as well as then adding mingw64 sub-RPMs The actual Fedora targetting Fedora 17 was simply to get the toolchain and basic runtime bootstrapped and into Fedora 17. The conversion of existing packages to add -mingw64 sub-RPM was not gated on Fedora 17, it was an asynchronous task. Most packages were converted via an out of tree testing repo ahead of the feature being propposed, to prove the viability of the work, so just needed to have pre-existing work merged. IIRC, Fedora 17 introduced mingw64 toolchain and converted alot of packages, and pretty much everything remaining was finished converting in F18 cycle. I think a feature page proposal is reasonable in suggesting the initial feature target is bootstrapping the base ucrt64 support and converting some common packages. I'm not quite so convinced by punting conversion of everything else to "other developers", with no expectation of when this work is to be completed. I fear this means alot of conversion just won't get done in a timely manner. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
