g-cpan is not up to the task of providing an ebuild for XML::SAX::Expat because 1. it seems to fail for several people, as mentioned in bug #152198 2. special care has to be taken for updates to ParserDetails.ini (bug #168988) As a lot of people might want to use this module (e.g. XML::Simple suggests its use) it might be nice to have an ebuild for this in portage.
Ebuild won't work either out of the box; the package-generated makefile is broken w/ sandbox, not g-cpan.
Since none of the reasons provided in comment #0 is valid any more, closing this bug. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap2
(In reply to comment #2) > Since none of the reasons provided in comment #0 is valid any more, closing > this bug. How so? Just because the cited bugs have been closed? Quoting from the Handbook > New Perl modules are to be added to portage only when one of the following > conditions is met: This ebuild meets two conditions, so I'd think it should qualify. > * The module(s) fulfill a dependency None that I'm aware of. The documentation in XML::Simple mentions it. > * The module(s) cannot be handled by g-cpan g-cpan is still not up to the task because a) it creates an ebuild for XML::SAX::Base, which is already installed as part of dev-perl/XML-SAX, causing a package collision. b) the default install process tries to register in ParserDetails.ini, leading to an error message, as the module has not been merged at that time. > * The module(s) add functionality to existing ebuilds Adds functionality to dev-perl/XML-SAX to allow use if Expat library. Adds Perl language bindings to dev-libs/expat. > * The module(s) provide tools, applications or other features (i.e. more than what their .PM offers) No.
Created attachment 144785 [details] Ebuild for dev-perl/XML-SAX-Expat-0.39 This ebuild is remotely based on one generated by g-cpan, but contains fixes to defer the call to XML::SAX->add_parser from the install to the postinst phase, as was done for dev-perl/XML-SAX in bug 168988.
Also docbook2X could use this to faster render man/info pages: http://docbook2x.sourceforge.net/latest/doc/dependencies.html
There is a new release, 0.40, with these changes according to the upstream change log: 0.40 2008-06-30 08:00 - small Kwalitee improvements Looks to be only small changes to documentation. My previously attached ebuild can be used without modifications, except for the ebuild name of course. Please, perl team, this is a small package with little activity (more than one year between releases), and in effect a simple and straightforward glue package between XML-SAX and XML-Parser. The ebuild itself is straightforward as well. It should be fairly easy to maintain. Bug 152198 comment 44 is a recent example for the fact that people still try and fail to install this via g-cpan. Please someone add this ebuild to the portage tree and be done with it.
(In reply to comment #6) > Looks to be only small changes to documentation. My previously attached ebuild > can be used without modifications, except for the ebuild name of course. Can you provide a matching pkg_postrm to remove the parser? Debian installs a script (update-perl-sax-parsers) with their libxml-sax-perl to do this. I haven't checked any other distribution.
Created attachment 163562 [details] Ebuild for dev-perl/XML-SAX-Expat-0.40 (In reply to comment #7) > Can you provide a matching pkg_postrm to remove the parser? Done. I'm a bit surprised that it's so easy, because even without checks for a present version the thing still works after re-merging it. Is that because postinst gets executed after postrm? dev-perl/XML-LibXML should probably get a similar postrm function, btw. > Debian installs a script (update-perl-sax-parsers) with their libxml-sax-perl > to do this. I haven't checked any other distribution. Just to keep the set of installed parsers up to date, this should not be necessary, I think. If every ebuild would clean up properly, there is no need for a command line tool, I think. If you need to influence the order of packages as well, then I think an eselect module would be the Gentoo way of doing things. I don't know which way the order of parsers is implemented, though, and there seems to be no API to control this order anyway. So I don't think that should be necessary either.
Created attachment 163564 [details] Ebuild for dev-perl/XML-SAX-Expat-0.40 Corrected die message. Should postrm die in case of an error? What if a user removes both XML-SAX-Expat and XML-SAX itself? In what order would they be removed? Should errors rather be ignored silently?
(In reply to comment #8) > dev-perl/XML-LibXML should probably get a similar postrm function, btw. Just filed bug 235502 for this. Which prooves that these parser removal lines are really needed.
dev-perl/XML-SAX-Expat-0.40 is in the tree now. Thanks. Let's see if pkg_postinst or pkg_postrm need further changes.
