Ryan Schmidt wrote: > On May 29, 2008, at 07:43, Tabitha McNerney wrote: >> For example, it might be a good idea to try and have as many >> dependencies for ports (whether build, run or library) be based on >> other ports rather than what Apple provides on the root filesystem >> because Apple can (and will) change their mind about things (which >> is fine with me just as long as for most if not all dependencies I >> can use MacPorts and not depend on Apple's frame of mind)! > > Which is precisely why the MacPorts project recommends that ports > depend on other ports, not on binaries or libraries that may be > installed on the system by Apple, whose versions or features could > change under our noses by a system update. > > http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries > > I'm not sure why the libiconv port was written differently here. > Looks like Mac OS X 10.4 provides gperf 3.0.1. MacPorts provides > gperf 3.0.3. Maybe I should change the port to use the gperf port > exclusively. It would be more consistent with our policy.
Back in the olden days of DarwinPorts, there were no such thing as port: dependencies. (They were added in 2005, r11790 if you're curious.) The libiconv port predates that, and I thought that might be why it uses bin:. However, it turns out that the gperf dependency was actually first added in r21556 in early 2007. Ironically, the exact issue of inconsistent features in the Apple-provided gperf was encountered shortly thereafter, and a port:gperf dependency was added, for darwin 7 only, in r21795. So yes, the dependency should probably be changed to port:gperf for all platforms. :-) - Josh _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users