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 - _______________________________________________ mingw mailing list mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mingw