I'm not 100% sure, but I think dev-perl/XML-Parser-2.460.0 should not force a dependency on dev-perl/libwww-perl, or at least not a build-time dependency. This is what I tried doing: 1. Copy XML-Parser-2.460.0 ebuild to my local overlay 2. Remove dev-perl/libwww-perl from the list of dependencies in my version of XML-Parser-2.460.0 ebuild 3. Emerge my version of XML-Parser-2.460.0 4. Run emerge --depclean and remove a lot of Perl-related dependencies (including dev-perl/libwww-perl) 5. Emerge XML-Parser-2.460.0 again, to be sure it builds successfully As far as I can see, XML-Parser-2.460.0 builds and installs successfully without dev-perl/libwww-perl. P.S. I was shocked when a few days ago I tried updating my Gentoo system and a lot on new packages were suddenly required (mostly Perl-related). I'm trying to keep my Gentoo system as minimal as possible, and this means installing the smallest number of packages.
Created attachment 731059 [details] emerge-info.txt emerge --info
There's a thread on the Gentoo forums on a similar problem: https://forums.gentoo.org/viewtopic-t-1140324.html
(In reply to Francesco Turco from comment #0) > [...] > As far as I can see, XML-Parser-2.460.0 builds and installs successfully > without dev-perl/libwww-perl. > Note that Perl dependencies are almost always runtime-only, even though sometimes they'll check in Makefile.PL. That is, they'll install fine, but may unexpectedly fail during runtime (possibly due to a conditional 'use XXX;' at any point). Running the test suite is probably as good as you can get to figure it out, or grep the upstream code. > P.S. I was shocked when a few days ago I tried updating my Gentoo system and > a lot on new packages were suddenly required (mostly Perl-related). I'm > trying to keep my Gentoo system as minimal as possible, and this means > installing the smallest number of packages. I did try to comfort you a bit on the forum. That said, I had a thought: USE=minimal may help on dev-perl/* by the way in package.use?
(In reply to Sam James from comment #3) > Note that Perl dependencies are almost always runtime-only, even though > sometimes they'll check in Makefile.PL. That is, they'll install fine, but > may unexpectedly fail during runtime (possibly due to a conditional 'use > XXX;' at any point). Running the test suite is probably as good as you can > get to figure it out, or grep the upstream code. I grepped the source code of XML-Parser, and I found references to "LWP", which I guess stands for libwww-perl. Please note that my knowledge of Perl is zero, so I'm not sure. (In reply to Sam James from comment #3) > I did try to comfort you a bit on the forum. That said, I had a thought: > USE=minimal may help on dev-perl/* by the way in package.use? I already enabled the "minimal" USE flag globally for my entire system, but it doesn't help unfortunately in this specific case. Anyway I solved my problem with system bloat by modifying the ebuild for sys-fs/eudev and getting rid of the dependency on dev-util/intltool, which is not needed, and has already been removed by Gentoo developers in the ~amd64 version (I'm running stable amd64). intltool was the only package requiring XML-Parser, and now they are both gone for good.
(In reply to Francesco Turco from comment #4) > (In reply to Sam James from comment #3) > > Note that Perl dependencies are almost always runtime-only, even though > > sometimes they'll check in Makefile.PL. That is, they'll install fine, but > > may unexpectedly fail during runtime (possibly due to a conditional 'use > > XXX;' at any point). Running the test suite is probably as good as you can > > get to figure it out, or grep the upstream code. > > I grepped the source code of XML-Parser, and I found references to "LWP", > which I guess stands for libwww-perl. Please note that my knowledge of Perl > is zero, so I'm not sure. > By gut, I'd say an XML parser may need one for loading external entities. https://metacpan.org/pod/XML::Parser seems to mention LWP with reference to that sort of thing. See also here: https://github.com/toddr/XML-Parser#externent--------expat-base-sysid-pubid. Now, that said? https://github.com/toddr/XML-Parser/blob/master/Makefile.PL#L117 only mentions LWP::UserAgent for tests. I think this might (not to put words in dilfridge's mouth) come down to us considering it a real runtime dependency and upstream might expect you to "just have LWP installed" if you want to use external entities. But I'm not sure. > (In reply to Sam James from comment #3) > > I did try to comfort you a bit on the forum. That said, I had a thought: > > USE=minimal may help on dev-perl/* by the way in package.use? > > I already enabled the "minimal" USE flag globally for my entire system, but > it doesn't help unfortunately in this specific case. > > Anyway I solved my problem with system bloat by modifying the ebuild for > sys-fs/eudev and getting rid of the dependency on dev-util/intltool, which > is not needed, and has already been removed by Gentoo developers in the > ~amd64 version (I'm running stable amd64). intltool was the only package > requiring XML-Parser, and now they are both gone for good. Yeah, finally done in bug 795795 (for stable now too a little while back).
I ran into problems on my virtual machines ("VMs") when updating pulse audio; I got an error message saying XML::Parser could not be found. I know Perl (my primary language at work). I'm going to scout around this forum and see, but I thought I'd register here I think there is a problem with the installation of Perl's XML::Parser module through Gentoo's dev-perl/XML-Parser ebuild. This problem has manifested itself on two VMs. Below are disparate results of XML::Parser 2.44 (works) vs. 2.46 which errors out. anus /usr/local/src/XML-Parser-2.46 # perl Makefile.PL Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. Install 'expat-devel' (or 'libexpat1-dev') package with your OS package manager. See 'README'. Or you can download expat from: http://sourceforge.net/projects/expat/ If expat is installed, but in a non-standard directory, then use the following options to Makefile.PL: EXPATLIBPATH=... To set the directory in which to find libexpat EXPATINCPATH=... To set the directory in which to find expat.h For example: perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include Note that if you build against a shareable library in a non-standard location you may (on some platforms) also have to set your LD_LIBRARY_PATH environment variable at run time for perl to find the library. janus /usr/local/src/XML-Parser-2.46 # cd .. janus /usr/local/src # cd XML-Parser-2.44 janus /usr/local/src/XML-Parser-2.44 # ls Changes Expat MANIFEST META.json META.yml MYMETA.json MYMETA.yml Makefile Makefile.PL Parser Parser.pm README inc samples t janus /usr/local/src/XML-Parser-2.44 # perl Makefile.PL Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. Install 'expat-devel' (or 'libexpat1-dev') package with your OS package manager. See 'README'. Or you can download expat from: http://sourceforge.net/projects/expat/ If expat is installed, but in a non-standard directory, then use the following options to Makefile.PL: EXPATLIBPATH=... To set the directory in which to find libexpat EXPATINCPATH=... To set the directory in which to find expat.h For example: perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include Note that if you build against a shareable library in a non-standard location you may (on some platforms) also have to set your LD_LIBRARY_PATH environment variable at run time for perl to find the library. Writing MYMETA.yml and MYMETA.json Generating a Unix-style Makefile Writing Makefile for XML::Parser Writing MYMETA.yml and MYMETA.json janus /usr/local/src/XML-Parser-2.44 # I created a simple test program to see if Perl could open the XML::Parser package -- the test failed: janus /home/jlpoole # cat test_xml_parser.pl use strict; use warnings; use XML::Parser; janus /home/jlpoole anus /home/jlpoole # perl test_xml_parser.pl Can't locate XML/Parser.pm in @INC (you may need to install the XML::Parser module) (@INC contains: /etc/perl /usr/local/lib64/perl5/5.34/x86_64-linux /usr/local/lib64/perl5/5.34 /usr/lib64/perl5/vendor_perl/5.34/x86_64-linux /usr/lib64/perl5/vendor_perl/5.34 /usr/lib64/perl5/5.34/x86_64-linux /usr/lib64/perl5/5.34 /usr/lib64/perl5/vendor_perl/5.32) at test_xml_parser.pl line 4. BEGIN failed--compilation aborted at test_xml_parser.pl line 4. janus /home/jlpoole # This may be a problem with the XML::Parser package and is compounded by the fact that the ebuild quietly fails. I tried re-emerging, and nothing was staged as a result although the emerge appears to have been successful. There should be an "XML" directory for the XML::Parser package stage in Gentoo's perl, but there is not. janus /usr/local/src/XML-Parser-2.44 # date Wed Dec 1 20:36:23 PST 2021 janus /usr/local/src/XML-Parser-2.44 # updatedb janus /usr/local/src/XML-Parser-2.44 # date Wed Dec 1 20:36:30 PST 2021 janus /usr/local/src/XML-Parser-2.44 # locate Parser.pm /root/.cpan/build/XML-Parser-2.46-0/Parser.pm /root/.cpan/build/XML-Parser-2.46-1/Parser.pm /root/.cpan/build/XML-Parser-2.46-2/Parser.pm /root/.cpan/build/XML-Parser-2.46-3/Parser.pm /root/.cpan/build/XML-Parser-2.46-4/Parser.pm /root/.cpan/build/XML-Parser-2.46-5/Parser.pm /usr/lib64/perl5/5.34/Pod/Simple/PullParser.pm /usr/lib64/perl5/5.34/TAP/Parser.pm /usr/lib64/perl5/vendor_perl/5.34/Module/Build/PodParser.pm /usr/lib64/perl5/vendor_perl/5.34/Pod/Parser.pm /usr/lib64/perl5/vendor_perl/5.34/x86_64-linux/HTML/HeadParser.pm /usr/lib64/perl5/vendor_perl/5.34/x86_64-linux/HTML/Parser.pm /usr/lib64/perl5/vendor_perl/5.34/x86_64-linux/HTML/PullParser.pm /usr/lib64/perl5/vendor_perl/5.34/x86_64-linux/HTML/TokeParser.pm /usr/local/src/XML-Parser-2.44/Parser.pm /usr/local/src/XML-Parser-2.46/Parser.pm /usr/share/texinfo/Texinfo/Parser.pm janus /usr/local/src/XML-Parser-2.44 # ls /usr/lib64/perl5/vendor_perl//5.34/x86_64-linux/ Bundle DBI Encode HTML Locale POD2 Scalar Sub Text Win32 dbixs_rev.pl DBD DBI.pm Encode.pm List Net SVN Socket6.pm Term Unicode auto encoding.pm janus /usr/local/src/XML-Parser-2.44 # You can see above my cpan attempts under root's directory and my staged area under /usr/local/src.
Bit tired so apologies if missing some nuance. Will read your comment again tomorrow. I was confused at first but I think(?) you were showing that if you try to manually install both an older & a newer version of XML-Parser, one will actually do some work, and the other will just bail out after the libexpat warning? What we really need to see is logs from the ebuild though, not manually running Makefile.PL. - My XML::Parser does have that subdir. Usually that error appears when a perl-cleaner --all run is needed (the error is slightly misleading; it's because the Perl installation is overall in an inconsistent state rather than _just_ that thing needing a reinstall usually.) You're saying that when you install an older XML-Parser, it's fine, but a newer one isn't? Please: - run perl-cleaner --all - post the build.log of XML-Parser - post the output of 'equery f XML-Parser'
It definitely is a runtime dependency, and likely also a test dependency.
The problem is the XML::Parser's installation. See https://github.com/toddr/XML-Parser/issues/93
Regarding the original bug, I read the source code and libwww-perl is indeed used to load external entities. By default, libwww-perl is used (when needed), but there is an option "NoLWP" in the constructor to not use it. If libwww-perl is not present, it will have the same behaviour as passing "NoLWP": it will load the external entities using file access (which will probably work for relative paths but fail otherwise). Entities are only loaded when "ParseParamEnt" option is enabled with a XML that has a DTD, or when a direct entity is referenced (which seems quite unlikely as most use-cases are not using direct entities). On my server the only package that uses XML::Parser is intltool, which doesn't use "ParseParamEnt" in the source code, and apparently a lot of the packages that depends on XML-Parser do so because they actually need it for intltool (system-config-printer, ddccontrol, gnucash). For other packages that depend on XML-Parser, xmltoman doesn't set ParseParamEnt, neither do sablotron or xmltv. So libwww-perl is indeed sometimes needed for XML-Parser to work as intended, but it's maybe not often the case. I think that disabling this libwww-perl dependency with a USE=minimal, as suggested in Comment #3, could be a workaround for those that have a small system and don't want a bunch of perl packages installed for nothing (I'm counting 23 dev-perl/* packages and 12 virtual/perl-* on my server).
Packages should not be explicitly depending on XML-Parser unless they need it by themselves outside of itstool. Having a flag for extra deps is only going to work if it's easy fo know whether your package uses the relevant functionality and that isn't trivial and adds significant maintenance burden.
