PyXML package - deprecate it?

[Toshio Kuratomi]

Just finished analyzing all of the packages that claim a PyXML dependency:

https://fedoraproject.org/wiki/User:Toshio/Remove_PyXML#Dep_analysis

There seem to be a hefty number of packages where we can remove the
dependency (the Easy fixes section).   I've opened bugs for those in
case the maintainers know something about the PyXML dep that I'm
unaware of.

Due to the fact that PyXML overwrites the python stdlib xml module the
possibility does exist that I've missed some feature that PyXML adds
to some portion of the stdlib xml module.  As an example of what level
of replacement that can occur: Both modules have sax.handler.  The sax
handlers can both be configured by setting  sax.handler.feature_*
attributes.  However, PyXML has feature_namespace_prefixes while the
stdlib module does not.  If you run across one of these in course of
trying to remove the PyXML dependency, please let me know, update the
wiki page, add to the bug report what's blocking things, etc.  I can
try to check for these things across all of the PyXML-using packages
if I'm made aware that they exist.

The Require Coding section is more problematic.  I'll list them all here:

* bkchem: uses xpath.  If this is all, it's probably doable to write a
patch that uses lxml's xpath instead.  Since it's a plugin, it's also
possible to stop shipping that plugin.
* libopensync-plugin-google-calendar: uses xpath.  Writing a patch
shoul dbe as doable as bkchem
* python-ZSI: I think we could fix with a package update.  Upstream
has a 2.1alpha1 release that Debian and Gentoo both ship that would
fix this for us.
* subscription-manager looks like it just needs a port to a different
library (the code isn't even xml related.. it's date parsing)
* spacewalk-backend: both uses of PyXML-only code were in test cases.
One looks like it could be ported to some other library (it's for
converting between character encodings).  The other one is for writing
xml using a SAX api.  I haven't looked at that one too hard  yet.
* openxcap makes use of a non-stdlib feature of the sax reader.  I
haven't looked into this one too hard either but I suspect there's not
just a drop-in replacement for this.  Some sort of custom code will
have to be written to handle what they're trying to do.
* comoonics* -- these packages make heavy use of the PyXML-only API.
I think someone will need to spend a while getting to know the code
and porting it to use a different library.  We could also drop the
comoonics packages until upstream ports.

rrakus, dmalcolm, others -- how do you want to proceed?  I can open
bugs for the remaining packages and we can plow forward on this but
some of the packages needing code changes may not make it for F18 and
have to be blocked.  We can also pursue one of the alternatives (for
instance, making the python2 stdlib not replace itself with PyXML and
patching those package swhich can't be ported in time to import
_xmlplus instead of import xml.

-Toshio