Hi, I didn't follow every single detail of the thread, but here are some random notes from me:
(0) Complaining that subversion is slow is highly unjustified. "sudo port selfupdate" on an rsync-based installation seems like it is taking forever (on a slow machine) as well. I might be biased because with "svn up" one sees that something is going on all the time, so time "runs faster". Certainly the first PortIndex run is as slow as it can be, but that's only one time. In any case comparing that to the build times of Qt (that René is primarily dealing with), the speed of svn is below any measurable threshold in my opinion. (1) Yes, the behaviour was confusing to me because I wouldn't expect the PortGroups to behave differently depending on location of the file. But it is also true that most developers (me included) only ever touch Portfiles and then maybe do some changes to the PortGroups because they miserably miss some functionality. Only few people dare to touch other files in _resources, so it would be natural to assume that the PortGroups should behave the same. But changing this is just a matter of documentation. All the PortGroups are relatively poorly documented and there is a lot of improvement that can and should be done in that respect. (2) About breaking functionality of ports in the main tree by adding a new PortGroup in a different tree: one can easily break functionality / binary reproducibility / incompatibility with prebuilt binaries just by adding an older or newer version of some port like libpng. As soon as one starts fiddling with a private tree it's super easy to end up in a broken state just like it's easy to do so when using some "inappropriate" flags when installing ports from the official tree. And helping those users will always be problematic. I would also like to see an option to override the global PortGroup, but then again I have commit rights, so when something is really important and globally useful, I can easily commit that change. Or I can do an exception and temporary add a complete local dports tree to the list of repositories while testing some new functionality. The crucial thing is to be aware that PortGroups do not override functionality in ports located elsewhere. (3) In my opinion the major problem that René (or [potential] users of his repository) is facing is probably the fact that those ports do no exist in the official repository. Most problems would likely vanish if users wouldn't have to fiddle with MacPorts to get those ports working. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev