Spec Name or Url: http://people.redhat.com/mitr/extras/python-4Suite-XML.spec SRPM Name or Url: http://people.redhat.com/mitr/extras/python-4Suite-XML-1.0-0.1.b2.src.rpm 4Suite-XML is a suite of Python modules for XML and RDF processing. Its major components include the following: * Ft.Xml.Domlette: A very fast, lightweight XPath-oriented DOM. * Ft.Xml.XPath: An XPath 1.0 implementation for Domlette documents. * Ft.Xml.Xslt: A robust XSLT 1.0 processor. * Ft.Lib: Various support libraries that can be used independently. --- Misc: - This is my first Extras package. I already have cvsextras access, nevertheless I'd like to be sponsored like anyone else would. - This package conflicts with 4Suite in Core; 4Suite will be removed from Core and replaced by python-4Suite-XML in Extras (which offers only a subset of the 4Suite functionality). - The package naming guidelines would suggest python-Ft or something like that, but python-4Suite-XML is only one of a family of 4Suite-* packages that should eventually use the Ft prefix.
What's going to happen about the rest of the 4Suite functionality?
4Suite-1.0b1 ("full") was split upstream, and 4Suite-XML-1.0b2 was released; upstream wants to "push 4Suite XML to 1.0 and then focus" on the remaining parts (RDF processing libraries, a XML/RDF repository and a http server). python-amara in Extras requires the XML libraries, so we need 4Suite-XML; the other parts will have to be left out until upstream returns to releasing them. Core used 4Suite only for the XML libraries in s-c-httpd, which was converted to use libxslt-python.
hmm. moin in extras can use 4Suite for xslt and docbook parsing for wiki pages. It doesn't have an explicit dep on it, though. thoughts?
From a quick look, moin seems to use only the libraries in 4Suite-XML.
Updated to 4Suite-XML-1.0b3. Could I get a sponsor to review the package, please? I'll promise to review >=3 other packages in return.
- Missing Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") - Doesn't contain any provision for .pyo files
- Hardcoded paths instead of macros (%{_datadir}, %{_libdir})
Thanks, all fixed in http://people.redhat.com/mitr/extras/python-4Suite-XML-1.0-0.2.b3.src.rpm .
Nitpicking from an outsider: Summary: Without trailing 's' from 'collections' it looks better, though I'm not an American English speaker. Also I would change Source0 to http://dl.sourceforge.net/foursuite/4Suite-XML-%{ver}.tar.bz2 or ftp://ftp.4suite.org/pub/4Suite/4Suite-XML-%{ver}.tar.bz2
Both fixed in http://people.redhat.com/mitr/extras/python-4Suite-XML-1.0-0.3.b3.src.rpm, thanks.
- Are the items in %{_libdir}/4Suite/profiles of any use? - Consider running %{_libdir}/4Suite/tests/test.py in %check
- I can't find any file or directory called "*profile*" in the built directory, have I missed anything? The tarball 4Suite-1.0b3/profile/ files don't look useful: a) upstream doesn't install them, why should we? b) at least profile_all.py references "create_document.py" and other test files which are not present in the tarball - the test suite fails, so it would just clutter the logs and new failures would be hidden among the "regular" failures. The test suite was failing in all 4Suite releases I have ever packaged, IIRC.
(In reply to comment #12) > - I can't find any file or directory called "*profile*" in the built directory, > have I missed anything? > The tarball 4Suite-1.0b3/profile/ files don't look useful: > a) upstream doesn't install them, why should we? > b) at least profile_all.py references "create_document.py" and other test files > which are not present in the tarball Interesting. Something in my environment must've caused the install script to create the dir. Oh well, not an big deal. > - the test suite fails, so it would just clutter the logs and new failures would > be hidden among the "regular" failures. The test suite was failing in all > 4Suite releases I have ever packaged, IIRC. Alright, I won't consider this a blocker then. APPROVED