PortGroup directory hierarchy/priority

[René J. V. Bertin]

Mojca Miklavec wrote:

> (1) Yes, the behaviour was confusing to me because I wouldn't expect
> the PortGroups to behave differently depending on location of the
...
> 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.

If you mean "behave the same as Portfiles", then yes.

> But changing this is just
> a matter of documentation.

Not entirely. I've long known how PortGroups behave; the reason this discussion 
got started was that I developed a doubt because of feedback I got from one of 
my users, and dared to raise the idea of changing this aspect.

> (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.

Exactly my argument.

> And helping those users will always be problematic. I would also like

Ditto. I'll add once more that all information in the main.log that underlines 
non-standard context will help in helping those users if they have issues.
That includes information that allows to identify which PortGroup is being read.

BTW, currently the log contains entries along the lines "Reading PortGroup 
foo-1.0.tcl" but that are logged *after* the file was read *successfully*. It'd 
probably be helpful to have a line that is output before the file starts being 
read, possibly even the filename in the :debug:bla: header. It could also be 
helpful to include the $Id line (or just the revision number), possibly from 
*every* file that's being parsed.


> 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.

Well, everybody can do that. I've often thought about it, but always decided 
against it until I have a 2nd OS X machine (which is unlikely to happen anytime 
soon).

> (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.

That's true for the KF5 ports, but at the same time (and the Qt5 dependency 
aside) they depend on a PortGroup that is also not part of the official trees. 
IOW, it would have been possible to enjoy my KF5 ports by simply adding my port 
tree without any need for "cross talk" if KF5 didn't need a patched Qt5 to 
function properly under MacPorts.
As it is, my Qt5 port must be used, and since that port is designed as an 
alternative to the official Qt5 port there is no other choice but to impose my 
Qt5 PortGroup to the whole ports tree.
That's not completely true; I could implement a hideous hack in the KF5 
PortGroup where it attempts to detect the "wrong" (= official) Qt5 PortGroup, 
undoes any side-effects like dependency declarations, and then includes mine. 
That however would mean it becomes impossible to build KF5 against the official 
Qt5 port, a possibility I've wanted to preserve explicitly (and transparently).


FWIW, I consider that just like with a *-devel port, it's the choice of which 
"flavour" a user installs that should determine how a dependent port builds. This 
is not situation where the dependent builds against a quartz vs. an x11 flavour 
of its dependency, or against different major, ABI-incompatible versions (say, 
llvm36 vs llvm38). No, port:qt5-kde was once port:qt5-mac +kde and was only 
split off as a separate port because shared maintenance of a single port is 
clearly not an option here, and also because KF5 ports have to be able to 
express at least a preferred dependency on the KDE flavour which is impossible 
with variants.

A final thought: testing my Qt5 port with dependents that aren't mine isn't 
helped by the fact that there are still so few Qt5 dependents. I'm however 
confident that the changes I've made to the Qt5 PortGroup are transparent as long 
as port:qt5-kde isn't installed, so it *should* be possible to commit them (to 
the svn tree first?) and see what happens ... (and how long it takes for the 
other maintainer to react ;) ). I've created a trac ticket just for the 
PortGroup, not more than 1 or 2 weeks ago (don't have the number handy, sorry).

R.