PortGroup directory hierarchy/priority

[Mojca Miklavec]

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