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 -