MinGW provides and requires automatic generation with RPM 4.9

[Panu Matilainen]

On 05/19/2011 01:49 PM, Kalev Lember wrote:
> 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}/.*$

Note that this doesn't work quite as you want it to, just yet: in rpm 
4.9.0 path and magic are handled as an inclusive or, whereas this (and 
various other things) needs an and-rule. Adding support for this is 
technically trivial, just the naming is under consideration: 
http://lists.rpm.org/pipermail/rpm-maint/2011-May/003022.html

> 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?

Depends on how soon your "soon" is :) - you'll probably want to wait 
until the and-rule support lands in rawhide rpm. OTOH if you're in 
hurry, I guess you could get away with just defining mingw32_magic and 
leaving the path out for now, Wine is probably the only thing besides 
mingw32 having Windows PE32 executables (and you could have an 
exclude-rule for the wine-paths just to be on the safe side).

> 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.

Nice to see folks finding use for it :)

	- Panu -