Description of problem: The update to 1.43 appears to have introduced an issue where rpm does not autogenerate the perl(DBD::Pg) virtual. So modules requiring this have to depend on perl-DBD-Pg rather than perl(DBD::Pg) (e.g. bugzilla #166191). The FC3 and FC4 packages do provide perl(DBD::Pg). Version-Release number of selected component (if applicable): perl-DBD-Pg-1.43-1 How reproducible: Easy Steps to Reproduce: rpm -q --provides perl-DBD-Pg Actual results: Pg.so perl-DBD-Pg = 1.43-1 Expected results: Pg.so perl(DBD::Pg) = 1.43 perl-DBD-Pg = 1.43-1 Additional info: Easy fix would just be to add the Provides: perl(DBD::Pg) = %{version} manually in the spec file.
Well, the bigger question is figuring out *why* it no longer auto-provides.
Created attachment 118587 [details] Patch to reformat Pg.pm so that perl.prov can interpret it properly (In reply to comment #1) > Well, the bigger question is figuring out *why* it no longer auto-provides. Good point. Patch fixes the formatting of Pg.pm so that auto-provides works again. Ideal fix would be for perl.prov to be able to parse the code as-is.
Thanks. Could you please submit this upstream too to make future maintenance easier? While I agree it would be ideal to fix perl.prov, that isn't a solution for older distros unfortunately. =(
Reported upstream: http://rt.cpan.org/NoAuth/Bug.html?id=14509
One theoretical point worth noting: Even though providing perl(DBD::Pg) in this package is correct, one could argue that packages in general should not have manually added dependencies on perl(DBD::*) in their specfiles. In the vast majority of use cases, the DBD::* drivers are not explicitly loaded in Perl code, but DBI loads the appropriate driver based on the data source given in connect(). Therefore, manually adding dependencies on perl(DBD::*) is kind of hardcoding assumptions about DBI's internals into specfiles, and in that sense, using the corresponding perl-DBD-* package names in dependencies wouldn't be that bad an alternative.
I've added a Provides: for this, should show up tomorrow in the FC-development release. regards, Florian La Roche
Ville, to clarify should we add the patch or a virtual provides?
As long as the package provides correct things, IMO the implementation is a matter of maintainer preference. I would have personally opted for the Provides too. (BTW, I don't see the change from comment 7 in CVS yet. )
Upstream reports that this is now fixed in CVS and "will appear correctly formatted in 1.44", so the manual Provides: should be removable when that version is released. http://rt.cpan.org/NoAuth/Bug.html?id=14509