On Tue, 21 Jul 2009, Dries Verachtert wrote:
On Sun, Jul 19, 2009 at 6:14 PM, Dag Wieers<[email protected]> wrote:
On Thu, 16 Jul 2009, David Steinbrunner wrote:
Christoph Maser wrote:
Am Dienstag, den 07.07.2009, 18:32 +0200 schrieb Joe Ogulin:
Error: Missing Dependency: perl(Normalize::Text::Normalize_Fields) is
needed by package
perl-MP3-Tag-1.11-1.el5.rf.noarch (rpmforge)
This one i broken. Seems like a mistake from find-requires skript. Is it
ok to simply put "Provides: perl(Normalize::Text::Normalize_Fields)" in
the spec of MP3-Tag? Or is there a way to remove things from requires
list?
The attached works for me. It was generated by cpanspec and I added lines
from the rpmforge spec to handle the man and bin files.
The reason why it works for you with that SPEC file is because the examples
are left out of the documentation.
There is this long-standing bug in RPM that also takes documentation into
consideration for the auto-requires and auto-provides. And the perl packages
are in fact very vulnerable to this.
The proper fix should go into perl.prov and perl.req and should consist of
ignoring documentation files. I don't know if this is already in bugzilla,
but if someone wants to do the effort to add it and make sure it gets fixed
upstreal, ths fix is quite easy (check if filename starts with
/usr/share/doc, and if so continue in the loop).
Since our SPEC files still need to work for RHEL3, RHEL4 and RHEL5. I don't
think we can realy on this fix in the foreseeable future though.
The patch in attach (has to be applied to /usr/lib/rpm/perl.req and
/usr/lib/rpm/perl.prov) ignores any files with a path containing
/usr/share/doc/. It seems to work ok on perl-MP3-Tag. I've no idea if
something like this will get accepted in the rpm projects but i'll
submit it anyway.
Please do ! :)
Dag: what do you think of applying this on the buildsystems so the
rpmforge perl rpms don't have this kind of problems anymore?
Well, it would mean that what we build from SRPMs is not identical to what
other people build. So I am against this, even though it would be the most
practical thing to do.
Shipping our own perl.req and perl.prov with every SPEC file is also not
really good practice. The only solution I see is our own macros package
that contains an improved perl.req and perl.prov (or a set of macros to
filter the output).
--
-- dag wieers, [email protected], http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
