On 11 Oct, 2007, at 16:00, Ryan Schmidt wrote:
On Oct 11, 2007, at 08:36, source_changes@macosforge.org wrote:
Revision: 29835 http://trac.macosforge.org/projects/macports/changeset/ 29835 Author: nox@macports.org Date: 2007-10-11 06:36:52 -0700 (Thu, 11 Oct 2007)
Log Message: ----------- py25-libxml2: * Changed docdir name into a versioned one. * Changed homepage to something more relevant. * libxslt is now directly disabled in setup.py, no more hazardous file delete calls.
You've replaced what looks like some simple code in the portfile to delete unwanted files.... with a whole bunch of Python code that will have to be maintained going forward. Is that really better? What was so hazardous about the "file delete" calls? Or is this Python code something that has been submitted upstream? That would be better since then we wouldn't have to maintain it.
(note: I maintain py-libxml2/py-libxslt/py25-libxml2 and I'm using the former names because they're easier to type and the ports are the same) Actually, what the patch does is to delete code from setup.py; it would otherwise build py-libxslt. There is not actually a separate package for py-libxml2 and py- libxslt upstream, and the way that these ports worked (prior to this patch) was to have both ports potentially build both packages, then strip out *xslt* from py-libxml2 and !*xslt* from py-libxslt. This change causes py-libxml2 to not build py-libxslt in any circumstance. It's potentially cleaner (and if setup.py changes, the patch will need to anyway). But, unless N_Ox has a way of making a symmetric change in py-libxslt, I'm going to revert the change. I am more concerned with guaranteeing that py-libxml2 and py-libxslt do not conflict than the extra CPU cycles to build them twice. Chris