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 -