Fix for #130376

[Evan Carroll]

I just wanted to rephrase the discussion because I'm not sure that
others will conclude it is "bit ridiculous". Not that I'm offended, he
is certainly entitled to that opinion. Personally though, I don't see
a single downside in it.

If a stable module is subclassed -- lets continue to use XML::SAX --
Debian will probably never have to patch it again. The module will
give you stability, security, and maintainability that isn't currently
enjoyed with the currently utilized monkey-patch in the same namespace
approach.

Lets show with code: http://gist.github.com/132074

Here we subclass XML::SAX this is my example of the The Right Way®.
What are we doing? Simple we defining just the Debian specific
functionality in an easily identified Debian specific module.
Conveniently, this patch would have never required a single change as
XML::SAX has evolved over the years. It is backwards-compliant and
almost indefinitely forwards-compliant too. That really doesn't matter
much though, because for the purpose of Debian they would be
distributing XML::SAX and XML::SAX::Debian. Why does it matter then?
Simple, updating a new version of libxml-sax-perl would be as simple
as repacking the CPAN tarbal. Debian hasn't given up control, they
have just delegated the initial workload of maintaining XML::SAX's
non-specific functionality back to PAUSE maintainer.

In five years, this will most probably still work with the newest HEAD
of XML::SAX. And, it will still add one sub, and short circuit one
sub. The great advantage here is that people who want to use XML::SAX
can do so.

Isn't this how Debian treats everything else? Does Debian pull other
upstream diffs onto their own local fork? Or, do they rebase patches
as necessary onto a fresh debian fork of the upstream stuff? It is
beyond me how it is a "bit ridiculous," to suggest you're better off
not redundantly maintaining all of cpan.

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..

Some interesting search results follow:
Duplicate on bugs.debian.org
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130376
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188410
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229178

http://scruss.com/blog/2008/05/17/how-to-fix-the-annoying-ubuntudebian-xmlsax-install-problems/
http://techero.wordpress.com/2008/02/12/problem-setting-up-libxml-perl-on-debianresolved/
http://ubuntuforums.org/showthread.php?t=214904
http://ubuntuforums.org/showthread.php?t=138392
There are 10 bug reports on launchpad related to it:
https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/13917
Fink bugs related to it as well
http://www.mail-archive.com/fink-users@lists.sourceforge.net/msg26097.html
136 pages on Google contain reports of this same thing.

Thanks again,


-- 
Evan Carroll
System Lord of the Internets