dev-perl/XML-SAX installs a file called ParserDetails where installed parsers should be listed. One such other parser is XML-LibXML. Right now this file is a normal installed file and thus overwrites the version already present with each upgrade: # emerge XML-LibXML ... # grep . /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini [XML::SAX::PurePerl] http://xml.org/sax/features/namespaces = 1 [XML::LibXML::SAX::Parser] http://xml.org/sax/features/namespaces = 1 # emerge XML-SAX ... # grep . /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini [XML::SAX::PurePerl] http://xml.org/sax/features/namespaces = 1 I can see three solutions: 1. Handle ParserDetails.ini in postinst phase, like XML-LibXML does 2. Config-protect ParserDetails.ini 3. Have an eselect module take care of managing ParserDetails.ini The first approach is more automatic, but if I understand things correctly the default parser is derived from the order in this file, which it would break. We might introduce a new configuration file where users can specify thir precedence of parsers, and have every parser-related ebuild update the ini file according to that file. This could be based on an eclass or an eselect module.
eselect module?! You are joking, right? o_O
Created attachment 111790 [details, diff] Patch to XML-SAX-0.15.ebuild moving ParserDetails.ini setting to postinst These modifications to the ebuild suppress the creation of ParserDetails.ini during the install phase completely. Instead a corresponding call is makde in postinst. The code there is taken from XML-LibXML but with an added "|| die". This approach will make the default parser setting dependant on emerge order, and as it is so far the ParserDetails.ini will still be around when you unmerge XML-SAX. I'm not sure what the right solution would be there. (In reply to comment #1) > eselect module?! You are joking, right? o_O I wasn't. Is eselect being deprecated, or is it simply not the right tool?
applied, thanks!
