On Oct 21, 2011, at 9:19 PM, David Evans wrote: > On 10/21/11 4:29 PM, Ryan Schmidt wrote: >> On Oct 20, 2011, at 17:35, David Evans wrote: >>> On 10/20/11 2:41 PM, Ryan Schmidt wrote: >>>> On Oct 20, 2011, at 15:15, devans wrote: >>>>> py26-atspi: add license, remove redundant dependency on python26. >>>> It wasn't particularly redundant, was it? py26-atspi does itself use >>>> python26, so it was appropriate for py26-atspi to list a dependency on >>>> python26. >>>> >>> By redundant, I meant that, in particular, py26-gtk declares a >>> dependency on python26 so it is not necessary to do so again. One could >>> argue that it isn't even necessary to declare python26 in py26-gtk, >>> since its dependents >>> py26-cairo and py26-gobject each declare it.
But in this case the only reason py*-gtk is a dependency is to build the tests. What happens if that goes away or gets moved to a variant (I would sure like not to suck gtk in just for the python module if I didn't need it) (strawman- yes I know wanting gnome bindings without already having gtk is of pretty limited likelihood, and that dbus-python26 also draws in python26) In this case it's probably pretty obvious that python is a requirement for py*-something and if you remove some other dependency you need to add a new one on python. But I've seen direct dependencies removed or omitted in the past because of this "something else I depend on will suck this in for me" model which is great at that time and saves a few bytes in the Portfile, but it makes understanding what the port really needs as things change in the future much harder (especially when you start reasoning like I don't need python because py26-gtk needs python, but py26-gtk doesn't need python because py26-cairo needs python. If any one of the ports in that chain changes you're missing a key dependency now). This port needs python26 directly to function. It never doesn't need it even if every other dependency could be removed. I think that is a good reason to explicitly list it as a dependency… Again, *this* port is not a great example of this being a problem, but this pattern I think is potentially dangerous and I don't think the guide really documents when it's ok not to list a dependency. When dependencies are listed only because something the port links against has that dependency and the library versioning causes trouble (libpng for a port whose source code doesn't actually contain any references to libpng) that's bad and I'm glad we can start getting rid of it. It is just as bad as not listing a dependency when trying to figure out what's going on in a port that you aren't intimately familiar with (X is broken, is there a way to make Y not depend on X?) Just an observation… Thanks, Eric _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
