Hello,
I poked a bit at the new RPM 4.9 dependency extraction system and it looks really nice. Right now we have the following boilerplate macros at the top of each and every mingw32- spec file:
%global _use_internal_dependency_generator 0 %global __find_requires %{_mingw32_findrequires} %global __find_provides %{_mingw32_findprovides}
With RPM 4.9 we can, finally, get rid of them.
The way the new dependency extraction system works is that we would drop a single mingw32.attr file in /usr/lib/rpm/fileattrs/, which defines a new "file attribute" definition. There are both file magic and path constraints, and if both match, our custom provides and requires extraction scripts are automatically called. This is the contents of the mingw32.attr file: %__mingw32_provides %{_rpmconfigdir}/mingw32-find-provides.sh %__mingw32_requires %{_rpmconfigdir}/mingw32-find-requires.sh %__mingw32_magic ^PE32 executable.* Intel 80386.*, for MS Windows$ %__mingw32_path ^%{_mingw32_prefix}/.*$
It should also be possible to use the new dependency extraction system in the mingw32-gcc package where we previously had to resort to manual mingw32(*) provides. The reason we previously couldn't define '_use_internal_dependency_generator 0' in that package is that the mingw32-gcc binary packages mixed both native binaries and cross compiled binaries; turning off dependency generator and replacing it with a mingw32 one would have resulted in no dependency generation for native binaries. But this should all work automagically now.
I am planning to add the new mingw32.attr file to the mingw32-filesystem package in rawhide soon. Any objections?
It might also make sense to mass rebuild all the mingw32 packages in rawhide with the boilerplate macros removed. This is also something I could do; would it be a good idea?
If it all works out nicely, we could also backport the mingw32-filesystem related changes to F15 (but not rebuild any other packages). The rationale for doing so is that packagers could then keep the F15 and rawhide spec files in sync, if they would want to do so. I would also like to note that supporting the new dependency extraction system in mingw32-filesystem shouldn't break existing packages that are still using the boilerplate macros at the top of the spec files.
Comments?
Oh, and thanks go to Panu Matilainen for the new RPM feature.