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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev