On 05/19/2011 03:11 PM, Erik van Pienbroek wrote: > Hi Kalev, > > Thanks for looking into this feature. > > While this feature sure looks interesting for the future I think it's > too soon to switch to this yet. As Panu indicated there are some things > which still need to be implemented (the and-rule) so this makes it > tricky to backport to old Fedora releases.
The missing "and-rule" would certainly be nice to have, but it is not a showstopper. A lot of different packages are working just fine without it in F15 and it's easy to make the mingw32 fileattr extractor also work without needing the "and-rule". As to exactly how, I have details in my reply to Panu. Most (if not all) "internal" dependency generators were converted over to the new fileattr based generators in RPM 4.9. Also several other high profile packages like cups, maven, and gstreamer have switched over in F15, which makes the mingw32 packages an exception, rather than a rule. We are the ones lagging behind. See for yourself, the following are all new fileattr generator types in use in F15 (yum provides '/usr/lib/rpm/fileattrs/*.attr'): desktop.attr elf.attr font.attr gstreamer.attr libsymlink.attr libtool.attr maven.attr mono.attr ocaml.attr perl.attr perllib.attr pkgconfig.attr psdriver.attr python.attr script.attr > Another issue is that we will > lose EL6 support if we're going to implement this in all mingw packages. > EL6 support is expected soon (as far as I've heard about it, various > mingw packages have popped up recently in the RHEL6 bugzilla) so it > wouldn't be really nice to break EL6 support so soon. Right, RHEL 6.1 was released today with a bunch of mingw32 packages. They are all, however, from the F13 era and if you want to build something mingw32 related in EPEL, it would also make sense to branch these packages from F13. For example, the mingw32-gtk2 package we have in rawhide / F15 would not work in EPEL 6 anyway, because the mingw32-glib2 in RHEL is too old. I am talking about changing the dependency generation in Fedora Rawhide (and also later backporting it to F15 to keep full srpm compatibility); the RHEL packages are free to keep carrying the boilerplate macros, nobody is breaking these. We are also retaining full compatibility with all old spec files. > I think it would be more sane to wait with implementing this future > until it has matured in RPM and is available in all current Fedora > releases. Sorry, but I disagree. Fedora Rawhide is exactly the place to innovate and not wait for RHEL to catch up. Also, keep in mind that the new dependency generation is fully compatible with all the old spec files. Older spec files that manually disable the "internal" dependency generator in the spec file are still going to work fine. -- Kalev _______________________________________________ mingw mailing list mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mingw
