Bugzilla Bug 168994

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 an attachment (id=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 an attachment (id=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 an attachment (id=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.