Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=483045
--- Comment #8 from Ralf Corsepius <rc040203(a)freenet.de> 2009-02-12 11:33:04 EDT
---
(In reply to comment #7)
Please help me to understand how to avoid such clashes in future
perl
package reviews?
These are hard to catch.
The only semi-systematic approach I am aware about is to iterate through
repoquery --whatprovides 'perl(..)' on all provides a perl package provides.
I only caught these in this particular case, because another package
BR'ed: perl(Test::Unit::TestCase),
which resulted into this:
# repoquery --whatprovides 'perl(Test::Unit::TestCase)'
perl-Test-Unit-0:0.25-4.fc9.noarch
perl-Test-Unit-0:0.25-4.fc9.noarch
perl-Test-Unit-Lite-0:0.1101-1.fc10.noarch
I think I just looked into code and see what META.yml said as
provides. Also, I successfully installed this package using rpm command where I
have already installed perl-Test-Unit.
Right, I am also observing this, but ...
what is
BR: perl(Test::Unit::TestCase)
supposed to do?
IMO, to pull-in the actual perl(Test::Unit::TestCase) module, i.e. the version
from perl-Test-Unit, not the "lite" version from perl-Test-Unit-Lite.
I fear, we are facing the tip of an iceberg of hidden issues.
Did I miss anything in this review for
such clash?
Strictly speaking, yes - but we all are humans :-)
I likely also would not have caught this.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.