Fix for #130376

[Niko Tyni]

On Thu, Jun 18, 2009 at 02:41:37PM -0500, Evan Carroll wrote:
 
> So again, consider the approach. I'm happy either way with a solution,
> and either way you porbably don't want your scripts using stuff in
> local, especially if the the result is that critical debian utilities
> can use it by accident making the whole system unsupported and
> unreliable. In retrospect, I'd probably not exclude the paths, but
> rather clobber @INC with whatever paths Debian will support.
> 
> Fixing this implementation woe will greatly improve usability.
> Researching this bug shows that it is really ubiquitous and
> bothersome..

Hi,

chiming in a bit late, some thoughts:

- patching update-perl-sax-parsers to remove /usr/local from @INC
  is a good idea IMO and should fix most of the trouble users are seeing
- I'd go with excluding the paths because otherwise we might need to
  change the script when perl @INC changes
- moving save_parsers_debian to XML::SAX::Debian could save some work,
  but I don't see the point in uploading it separately to CPAN and having
  it in a separate Debian package
- I think we'd still need to patch our XML::SAX::save_parsers(),
  otherwise people installing (say) XML::SAX::Expat from CPAN over our
  libxml-sax-perl will write in /usr/share/perl5/XML/SAX/ParserDetails.ini
  while the active file is in /etc/perl and managed by update-perl-sax-aparsers
- any transition involving update-perl-sax-parsers, especially one
  that changes package dependencies, will need some extra care because
  the script is called from preinst scripts and the like

Thanks for bringing this up,
-- 
Niko Tyni   ntyni at debian.org