On Sat, 21 Feb 2026 at 09:08, Richard W.M. Jones <[email protected]> wrote: > > On Fri, Feb 20, 2026 at 11:06:50PM +0000, Jonathan Wakely wrote: > ... > > > > Actually, it might not be tooooo painful: > > > > https://src.fedoraproject.org/fork/jwakely/rpms/boost/diff/rawhide..mingw > > > > > > > > One of the mingw-specific patches no longer applies to boost-1.90.0 > > > > (and would completely break the min-mingw native package builds > > > > anyway) so that needs addressing by somebody. > > > > > > > > I've only tested 'fedpkg prep' so far, so I have no idea if the rest > > > > of it works. > > > > > > The %files will obviously fail, because the list of libs in > > > boost-1.90.0 is very different. But is there any reason that the mingw > > > %files don't just use wildcards? It looks like that would be vastly > > > simpler. I've pushed a second commit to the branch that does that. > > I kicked off a scratch build in Koji: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=142580007 > > The actual change looks quite a lot simpler than I was expecting. > > I'm a bit surprised that 'file' and 'perl-interpreter' are needed by > mingw but not by the native package. Those may be left overs?
Yes, probably. I decided not to dig into that at 11pm on a Friday. > > Is it safe to create directories (like ../win32) in the parent of the > build directory? I think so, because all the build happens inside the boost_1_90_0 directory, so shouldn't care that there are other directories in the parent. > And then the build actual uses "pushd win32" (not > "pushd ../win32"). I wonder if the scratch build will fail on this. Oops, yes that will probably fail. (And I've just seen your follow-up mails). > > I agree about simplifying %files. Basically reducing the delta > between native and mingw, and generally reducing the packager > workload, are the important factors. > > Ultimately the decision about this is entirely up to you. I'm a bit concerned that this will make the annual-ish task of updating boost in rawhide even harder, because I'll also have to debug build failures for the mingw package. I have almost zero experience of mingw packaging in Fedora (my usage of mingw is limited to a bit of testing std::filesystem code in libstdc++), and the Boost build system is already hard enough to control for a native linux build. It already takes 2-3 weeks to do a boost rebase. The mingw-boost packages are also not used in RHEL. The main reason that Red Hat wants me to maintain boost is because we depend on it for RHEL. If I end up spending significant time debugging mingw problems, that's not something I can easily justify to work, and not something I would choose to do voluntarily as a Fedora maintainer. If I can lean on the mingw mailing list for support, I'm willing to try it. But if it proves too painful I might ask to revert the changes and split mingw-boost out again in a couple of years. Which would presumably involve some admin to resurrect the retired standalone mingw-boost package. -- _______________________________________________ mingw mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
