PortGroup directory hierarchy/priority
René J. V. Bertin
rjvbertin at gmail.com
Wed Apr 6 02:19:55 PDT 2016
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
> (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
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
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).
More information about the macports-dev