Created attachment 775838 [details] emerge info What do these scary messages actually mean for my system? * Messages for package dev-perl/XML-SAX-Expat-0.510.0-r1: * To remove XML::SAX::Expat run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::SAX::Expat))->save_parsers()' * Messages for package dev-perl/XML-LibXML-2.20.700: * To remove XML::LibXML::SAX::Parser run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX::Parser))->save_parsers()' * To remove XML::LibXML::SAX run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX))->save_parsers()' Do I need to do that? Do I not need to do it unless something (what)? If I need to do it can I safely reboot before doing so (since I don't know whether to do it or not ATM)? Maybe it was an artifact of the replacement that's already taken care of and I need do nothing? In fact, maybe actually doing what it says will kill the new version? No clues at all in the messages. I checked the (-Expat) ebuild for related comments and wasn't much more enlightened, except to look at bug #840053, which seems to indicate it's due to a change in EAPI7 or 8, with a fix supposedly already there now except... not, as it still doesn't really tell me what I need to do, especially since based on that bug I'd guess ROOT= should be empty (I've not actually debugged what it was yet but obviously the -z test was false), since I'm doing an ordinary install to /. ~amd64 no-multilib, with reverse-usrmerge (aka /usr -> . ) in case that matters. The three involved ebuilds that were upgraded in that run from the --ask output, thus including USE flags and previous versions: [ebuild U ] dev-perl/XML-SAX-1.20.0-r1::gentoo [1.20.0::gentoo] USE="-test" 0 KiB [ebuild U ] dev-perl/XML-LibXML-2.20.700-r2::gentoo [2.20.700::gentoo] USE="-examples -minimal -test" 0 KiB [ebuild U ] dev-perl/XML-SAX-Expat-0.510.0-r3::gentoo [0.510.0-r1::gentoo] USE="-test" 0 KiB I'm attaching emerge --info with this and will add the logs afterward.
Created attachment 775841 [details] XML-SAX-Expat emerge log OK, after modifying the -Expat -r3 ebuild adding an elog like this (added line outdented): 46 pkg_update_parser() { 47 # pkg_update_parser [add|remove] $parser_module 48 local action=$1 49 local parser_module=$2 50 elog ROOT=${ROOT} 51 if [[ -z "${ROOT}" ]] ; then 52 einfo "Update Parser: $1 $2" 53 perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ 54 || ewarn "Update Parser: $1 $2 failed" 55 else 56 elog "To $1 $2 run:" 57 elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" 58 fi 59 } ... I tried remerging over top. No message. But remerging the old -r1 binpkg (which I still have due to FEATURES=buildpkg) and then -r3 (not binpkg) to get the upgrade again, I do get a message. Log excerpt (starting with the last of the old-pkg unmerge after the upgrade): <<< dir /usr/share/doc/XML-SAX-Expat-0.510.0-r1 * To remove XML::SAX::Expat run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::SAX::Expat))->save_parsers()' >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. * ROOT= * Update Parser: add XML::SAX::Expat >>> dev-perl/XML-SAX-Expat-0.510.0-r3 merged. * Messages for package dev-perl/XML-SAX-Expat-0.510.0-r1: * To remove XML::SAX::Expat run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::SAX::Expat))->save_parsers()' * Messages for package dev-perl/XML-SAX-Expat-0.510.0-r3: * Log file: /lg/portage/dev-perl:XML-SAX-Expat-0.510.0-r3:20220502-041841.log * ROOT= >>> Auto-cleaning packages... So the new -r3 (with my ROOT= elog) merged correctly, following the empty ROOT branch as expected. The confusing/scary message then comes from the unmerge of the old -r1 (without my added ROOT= elog). That's actually what I suspected, but I still am no closer to knowing whether I actually need to run the suggested removal, or if doing so would actually remove something pertaining to the NEW version that replaced the old one that's generating the message. Presumably we can't change what the old version prints on removal (?). What about taking a hint from the way the xorg logs seem to handle something like this? Put in the new message what to do (disregard the following... assuming it should be ignored, or please run the following command if it appears... assuming it should be followed) if the old message comes up?
Created attachment 775844 [details] XML-LibXML emerge log To ge the LibXML log I used the (unmodified ebuild) binpkgs for both the downgrade and the re-upgrade. Note in the excerpt below that only the Messages... part appears in a normal parallel-emerge system upgrade, where the individual logs aren't normally printed, and that only contains the "remove" bit from the unmerge of the old version, not the "Update Parser: add" bit, making the message that still appears even more confusing: <<< dir /usr/share/doc/XML-LibXML-2.20.700 * To remove XML::LibXML::SAX::Parser run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX::Parser))->save_parsers()' * To remove XML::LibXML::SAX run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX))->save_parsers()' >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. * Update Parser: add XML::LibXML::SAX::Parser * Update Parser: add XML::LibXML::SAX >>> dev-perl/XML-LibXML-2.20.700-r2 merged. * Messages for package dev-perl/XML-LibXML-2.20.700: * To remove XML::LibXML::SAX::Parser run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX::Parser))->save_parsers()' * To remove XML::LibXML::SAX run: * perl -MXML::SAX -e 'XML::SAX->remove_parser(q(XML::LibXML::SAX))->save_parsers()' >>> Auto-cleaning packages... Given the order in the full log, it appears the skipped removes for the old version happen before the not-skipped adds for the new version, so I *THINK* everything should be fine without me doing anything. But I'm still not sure, and the abbreviated output messages from a parallel merge (as I initially did) only show the confusing out-of-context remove instructions. Would actually following them be as harmful to the functionality of the package as I think it would be?
This predates me and I need dilfridge help on this.
