MinGW provides and requires automatic generation with RPM 4.9

[Kalev Lember]

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.

-- 
Kalev