Hide Forgot
Description of problem: It is possible to pass a reference to a variable containing the ini "config file" to Config::IniFiles->new() This feature requires IO::Scalar to be installed. However, rpmbuild doesn't pick this dependency automatically. Version-Release number of selected component (if applicable): perl-Config-IniFiles-2.68-1.fc16.noarch How reproducible: Always Steps to Reproduce: 1. yum install perl-Config-IniFiles 2. Run the following perl script: -- test.pl -- use Config::IniFiles; my $ini = "[section]\nkey=value"; my $config = Config::IniFiles->new(-file=>\$ini); ------------- Actual results: On a system without perl-IO-stringy installed, I get: [mathieu@localhost ~]$ perl test.pl Failed to open SCALAR(0x1034c48): No such file or directory at test.pl line 5 This means that the package is missing a requires on perl(IO::Scalar) Expected results: The script should not fail, because perl-IO-stringy would be installed. Additional info: The problem is present both in Fedora 16 and EPEL 6, probably in other releases as well. Note that the requirement should probably be picked up by rpmbuild, my guess is that rpmbuild doesn't like the way IO::Scalar is used in Config::IniFiles: -- lib/Config/IniFiles.pm:2265 -- if (ref($thing) eq "SCALAR") { if (eval { require IO::Scalar; $IO::Scalar::VERSION >= 2.109; }) { return IO::Scalar->new($thing); } else { warn "SCALAR reference as file descriptor requires IO::stringy ". "v2.109 or later" if ($^W); return; } } --------------------------------- Perhaps it could be added to the spec file in the meantime?
I didn't actually verify the bug in Rawhide, so I'm setting the Version to "Fedora 16". Sorry for the extra email, I should have paid more attention before submitting the bug.
perl-Config-IniFiles-2.68-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Config-IniFiles-2.68-3.el6
perl-Config-IniFiles-2.68-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Config-IniFiles-2.68-3.fc16
perl-Config-IniFiles-2.68-3.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Config-IniFiles-2.68-3.el5
perl-Config-IniFiles-2.68-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Config-IniFiles-2.68-3.fc17
perl-Config-IniFiles-2.68-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Config-IniFiles-2.68-3.fc15
Package perl-Config-IniFiles-2.68-3.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Config-IniFiles-2.68-3.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-2142/perl-Config-IniFiles-2.68-3.fc15 then log in and leave karma (feedback).
perl-Config-IniFiles-2.68-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
perl-Config-IniFiles-2.68-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
perl-Config-IniFiles-2.68-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
perl-Config-IniFiles-2.68-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
perl-Config-IniFiles-2.68-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
There is no EL6 version of perl-IO-stringy, so this change breaks perl-Config-IniFiles on EL6.
(In reply to Konstantin Ryabitsev from comment #13) > There is no EL6 version of perl-IO-stringy, so this change breaks > perl-Config-IniFiles on EL6. Yes there is; it's in RHEL (optional), and CentOS (see Bug #884802).
You are correct, of course. For some reason this particular server didn't have the optional channel on. Sorry for the noise.