Description of problem: texinfo-5.0 contains perl modules, which are not being installed into the standard perl search paths. rpm's perl(<perl-modules>) requires/provides however presume the modules to be installed under standard perl search paths. => texinfo-5.0 must not rpm-provide/requires perl(<perl-modules>) for those modules it installs into its private directories. Version-Release number of selected component (if applicable): texinfo-5.0-2.fc19 Actual results: check the output of rpm -q --requires -p texinfo-5.0-2.fc19.x86_64.rpm | grep 'perl(' rpm -q --provides -p texinfo-5.0-2.fc19.x86_64.rpm | grep 'perl(' Expected results: texinfo not to provide/require private perl-modules through "perl(..)". Additional info: - You likely need to filter them out. - As some of these modules are bundled duplicates of cpan modules (Another bug in texinfo's current packaging), these provides/requires are harmful and cause broken deps.
(In reply to comment #0) > - You likely need to filter them out. Another possibility would be to install them in the normal paths. In fact, the perl modules have a sort of dual possibility for installation, they may be installed as private modules, and then spurious deps needs to be filtered out, but it may also be possible, with more work, to take advantage of the possibility to install them as regular perl modules. Indeed, if you look at the directory tp/ and the directory Pod-Simple-Texinfo/, both have a Makefile.PL that should allow to build/install the Texinfo and Pod::Simple::Texinfo modules as regular perl modules. In tp/ you may need to run ./maintain/regenerate_perl_module_files.sh and, since this regular perl modules handling is not tested a lot, there may be issues, but it should certainly be possible to make it work. You'll have to make sure that you install the scripts that correspond to the correct possibility, which is, most likely the configure based one. The checks should be done from the configure based possibility, as the command is not tested in the perl only case. > - As some of these modules are bundled duplicates of cpan modules (Another > bug in texinfo's current packaging), these provides/requires are harmful and > cause broken deps. This should be fixed in any case, but unless I am wrong this is on the way to being fixed.
Thinking a bit more, if you want to go to the native perl install of modules possibility, maybe it would be better if I tried to do something first and I propose a patch to the spec file, and also wait for the next release such that I test it prior to the release.
(In reply to comment #1) > (In reply to comment #0) > > > - You likely need to filter them out. > > Another possibility would be to install them in the normal paths. Agreed. However, in advance to doing so, one needs to check if they'ed potentially clash with CPAN, because texinfo's perl modules are not part of CPAN, but if not (Which I would expect to apply), this would have many advantages. I am in favor of doing so. > > - As some of these modules are bundled duplicates of cpan modules (Another > > bug in texinfo's current packaging), these provides/requires are harmful and > > cause broken deps. > > This should be fixed in any case, but unless I am wrong this is on the way > to being fixed. Right - After having filed this BZ, I also noticed this :-)
(In reply to comment #3) > (In reply to comment #1) > > (In reply to comment #0) > > > > > - You likely need to filter them out. > > > > Another possibility would be to install them in the normal paths. > Agreed. However, in advance to doing so, one needs to check if they'ed > potentially clash with CPAN, because texinfo's perl modules are not part of > CPAN, but if not (Which I would expect to apply), this would have many > advantages. The texinfo modules are not in CPAN, and I am still unsure if I want to maintain them in CPAN, in addition to having them in texinfo (I think I am certainly the logical maintainer in CPAN since I develop them in texinfo, though somebody else than me may want to maintain them in CPAN). But even if they were in CPAN, I think that they should still come from texinfo in Fedora, because the CPAN version will certainly always be lagging, and except for this lagging should (hopefully) be exactly the same than in texinfo. > I am in favor of doing so. I am too, although maybe not for this release, but for the next one.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > (In reply to comment #0) > > > > > > > - You likely need to filter them out. > > > > > > Another possibility would be to install them in the normal paths. > > Agreed. However, in advance to doing so, one needs to check if they'ed > > potentially clash with CPAN, because texinfo's perl modules are not part of > > CPAN, but if not (Which I would expect to apply), this would have many > > advantages. > > The texinfo modules are not in CPAN, and I am still unsure if I want to > maintain them in CPAN, That's not what I was suggesting. I meant, before Fedora tries to install texinfo's perl-modules into Fedora's system-perl (Which is technically not much of a problem), the Fedora maintainer needs to check if some other perl-module in CPAN could potentially clash with such perl-system installed texinfo modules. > > I am in favor of doing so. > > I am too, although maybe not for this release, but for the next one. Are you talking about upstream or Fedora's packaging? I am referring to Fedora-19's texinfo and would suggest Fedora 19's texinfo perl-modules to be installed into the perl-system dirs (I am doing something similar, e.g. for rt3).
(In reply to comment #5) > That's not what I was suggesting. I meant, before Fedora tries to install > texinfo's perl-modules into Fedora's system-perl (Which is technically not > much of a problem), the Fedora maintainer needs to check if some other > perl-module in CPAN could potentially clash with such perl-system installed > texinfo modules. Ah, ok. I tried to do that when giving names to the Texinfo modules upstream, but I haven't done something very systematic. > > > I am in favor of doing so. > > > > I am too, although maybe not for this release, but for the next one. > Are you talking about upstream or Fedora's packaging? I am referring to > Fedora-19's texinfo and would suggest Fedora 19's texinfo perl-modules to be > installed into the perl-system dirs (I am doing something similar, e.g. for > rt3). I am talking about both upstream and Fedora's packaging. More precisely, if the Fedora packagers want to install the perl modules in the system perl directory that's fine, and better. However, now with my upstream hat, I haven't tested lately, and in particular I forgot to test before the release, that the standalone perl modules installation was up to date, and was still working, but I will do it seriously for the next upstream release, so it may be convenient for the Fedora packaging to wait. Also maybe doing something similar with other distros may be worth it, the debian packager, in particular is very proactive.
Created attachment 701735 [details] checks and install modules in perl paths In the attached spec files there are some modifications you are not interested in, such as using the Unicode::EastAsianWidth dependencies, not applying some patches, one less source. There are 2 interesting unrelated modifications you are certainly interested in. First, checks are enabled. This means BuildRequires: perl(Locale::Messages), perl(Unicode::EastAsianWidth), perl(Text::Unidecode) and the %check section. You can remove the export line if you want shorter tests. The other change is the installation of perl modules in system paths. It uses a script ./maintain/prepare_perl_module_files.sh that will only be present in the next release. You could take it from the svn sources if you want to, though. I only have tested the svn sources (and tested only the build and rpmlint). Another unrelated point, I think that the texinfo package itself is now noarch, now that it is perl only. The next release should hopefully be released rather soon, because of bugfixes.
The new release is out, and so I believe my proposals in Comment 7 could be used.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
I can't build emacspeak in f22 Rawhide currently: : make[1]: Entering directory '/builddir/build/BUILD/emacspeak-39.0/info' makeinfo --force -o emacspeak.info emacspeak.texi Can't locate Unicode/EastAsianWidth.pm in @INC (you may need to install the Unicode::EastAsianWidth module) (@INC contains: /usr/share/texinfo /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/texinfo/Texinfo/Convert/Unicode.pm line 31. BEGIN failed--compilation aborted at /usr/share/texinfo/Texinfo/Convert/Unicode.pm line 31. Compilation failed in require at /usr/share/texinfo/Texinfo/Convert/Text.pm line 27. BEGIN failed--compilation aborted at /usr/share/texinfo/Texinfo/Convert/Text.pm line 27. Compilation failed in require at /usr/share/texinfo/Texinfo/Parser.pm line 55. BEGIN failed--compilation aborted at /usr/share/texinfo/Texinfo/Parser.pm line 55. Compilation failed in require at /usr/bin/makeinfo line 101. BEGIN failed--compilation aborted at /usr/bin/makeinfo line 101. Makefile:41: recipe for target 'emacspeak.info' failed
Okay I was caught be the mentions of "Unicode::EastAsianWidth" in comment 7. Sorry for the noise I guess above is a new issue with texinfo-5.2-6.fc22.
Should be fixed in texinfo-5.2-7.fc22. I filtered false perl provide/require out. (I wasn't able provide unique texinfo's modules - IIRC prepare_perl_module_files.sh doesn't work on armv7hl or is missing some dependency maybe...). I also enabled test (%check) during build, thanks for that Patrice!