On Thu, Feb 10, 2022 at 10:29:14AM +0100, Sandro Mani wrote: > > On 07.02.22 11:07, Sandro Mani wrote: > > > > > Yes, I proposed that last year. I was supposed to move it forward by > > > providing a copr repo illustrating it in real world, but I'm afraid > > > I got side tracked. > > > > I also wasn't able to participate in the discussion having had too much > > going on then, but I'd be happy to help (re-)launching the effort. > > I'd like to start working on this with some of my packages, I'd handle this > similarly to say mpi builds, just manually adding the required steps in > %build and %install and adding subpackages as necessary, then retiring the > respective mingw repo. Any objections to this? FWIW, my proof of concept last year did the following to the libvirt-glib.spec file: https://gitlab.com/berrange/libvirt-glib/-/commit/45994bf93bb4b030e3ab57c9b2e4e61e737d6d29 As you can tell, it is essentially just the contents of the current mingw-libvirt-glib.spec file: https://gitlab.com/berrange/libvirt-glib/-/blob/mingw-rpm-merge2/mingw-libvirt-glib.spec.in copied over into the libvirt-glib.spec To repeat my previously reported interesting notes: * We need to set mingw32_pkg_name/mingw64_pkg_name explicitly because the current logic that sets these doesn't work: %mingw32_pkg_name %(echo %{name} | sed 's/^mingw-/mingw32-/') Presumably we can fix that macro so that it does the right thing when no mingw- prefix exists in the first place * We can't use %mingw_package_header because that splatters the native debuginfo generation. So we must explicitly add mingw debuginfo packages by referencing %{?mingw_debug_package} and at end of %install add %mingw_debug_install_post * %mingw_package_header has reference to overriding strip/objdump to prevent corruption of binaries. We can't do that override because we need native strip/objdump for the native builds. AFAICT though, no corruption happened to my DLLs even without this strip/objdump override. Looks like this caveat might be obsolete, unless the scenarios it hits are more niche than I tested. * %mingw_package_header tries to disable the internal dependancy generator on RHEL 6. For reasons I don't understand, it ends up disabling it on Fedora too. %mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ %if 0%{?rhel} == 6 \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{mingw_findrequires} \ %global __find_provides %{mingw_findprovides} \ %endif \ %global __debug_install_post %%{mingw_debug_install_post} \ %{nil} The last two points feel like simple bugs we need to fix regardless. 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
