Some of your Debian packages might need attention (libxml-sax-perl #430118)

[Niko Tyni]

(let's move this from pkg-perl-maintainers to the relevant
 bugreport, #430118)

On Tue, Jul 03, 2007 at 03:22:35PM -0400, Jay Bonci wrote:

>     I'm looking at the XML::SAX thing right now. There are a couple of
> solutions. 
> 
>     One of which is to simply reorder the final list with some perl hack so
> that XML::SAX::PurePerl is never set as the default unless it started that
> way. 

Yes, I think this is the minimal required change. It would emulate
the upstream behaviour for the most important part: all other parsers
override XML::SAX::PurePerl.

There's another problem about the current update-perl-sax-parsers system:
it's misusing /etc, since local changes are not preserved on upgrades.
Of course, there isn't much to really configure, but if somebody wants
to eg. remove XML::SAX::PurePerl from /etc/perl/XML/SAX/ParserDetails.d
(or truncate it to get the same effect), it's going to come back on
each upgrade.

I think it would be better to store the parser details under /var, say 
/var/lib/libxml-sax-perl/ParserDetails.d, since their content is not
really configuration data anyway. 

The resulting configuration file, /etc/perl/XML/SAX/ParserDetails.ini,
should be handled so that local configuration changes are preserved.
This could be done with eg. ucf.

>     The suggested method in the bug of a SAX-based priority parser election
> doesn't really seem to make good organizational sense. It'd have to be a
> fairly large upstream change to the file, which we could work out if that's
> kind of what everbody wants.

FWIW, I would also prefer a priority-based system where the priorities
could be configured by the local administrator (but would have reasonable
defaults, of course.) This would make the behaviour more deterministic,
as packages could specify sensible priorities instead of being stuck
with the filesystem ordering of their names.

I don't think the format of the files need to be changed for this; the
priority could be encoded to the filename, preferably via symlinks as
usual with the *.d stuff.

This would need one more level of indirection; the current
/etc/perl/XML/SAX/ParserDetails.d directory could be reused for the
symlinks into /var/lib/libxml-sax-perl/ParserDetails.d. The links could
be named eg. "NN-<parser>", with NN specifying the priority and <parser>
the name of the parser.

Obviously, a symlink should only be created if there isn't a file
referring to the same parser already (to cater for local priority or
content changes). Preserving symlink removal by the administrator is a
bit harder, and would probably need an interface change so that other
packages would invoke update-perl-sax-parsers with different arguments
on upgrade and the initial install.

I can write a more detailed proposal if this sounds desirable; please
let me know what you think about this.

Cheers,
-- 
Niko Tyni   ntyni at iki.fi