On 05/19/2011 03:11 PM, Erik van Pienbroek wrote:
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'):
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
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.