PortGroup directory hierarchy/priority

[René J. V. Bertin]

Clemens Lang wrote:

Hi,

> Builds can be made bit-by-bit reproducible even when building from
> source. It's not even particularly difficult for a lot of ports, as long
> as the toolchain stays the same, timestamp issues are handled and the
> environment the software builds in is under close control (e.g. a
> chroot).

The problem is that you don't have that close control over a user's machine, if 
not only because MacPorts "base" is fully open source.
Theoretical argument against theoretical argument (as long as we leave the -
devel ports out of the equation) ;)

>> However, my argument still stands that the developer of that port and
>> PortGroup would be subject to the same thing. There's indeed a trust
>> issue there, but one that goes both ways.
> 
> Yes, developers of separate port trees implicitly trust the main port
> tree. I don't think that's the same situation, though, because the same
> developers also wrote MacPorts base, which they also implicitly trust.

I meant something else: trust in the developers of external trees (that they 
don't have malicious intentions for instance).

> No. Modifications of PortGroups do not trigger re-indexing unless you
> also touch the Portfiles that use it.

That reminds me of a discussion a while back on how Portfile changes are detected 
(and where the files are expected). Would it be very costly to replace the ascii 
portindex files with sqlite3 databases that store more information, including 
references to included PortGroups? I mean runtime cost, implementation of 
something like that seems like a nice summer project for someone.

> Yes, manpower is one of our general problems. We should try to improve
> our buildbot setup to provide more automation (e.g. Continous
> Integration) -- that would at least simplify test coverage. As you may
> have seen, we have actually started looking into this at MacPorts
> Meeting 2016 in Slovenia last month.

No, I didn't see that. But I'm not sure that would really help here beyond 
finding build issues on OS versions that I cannot test. In this particular case 
things block because the maintainers of the official ports are very busy and 
maybe even more "I prefer to do it my way, myself" than I am (presumably because 
they developed the ports in question because they need them for their real work, 
which is also the main reason for my own involvement).
Initially I thought it'd help if I went out of my way to make my qt5-kde as much 
as a drop-in replacement as possible, like a more common *-devel port. Now, I'm 
no longer so sure but I'd hate to have wasted even more effort on a Qt port and 
I'm also really not sure it'd be a good idea to allow 2 parallel Qt5 installs in 
a single MacPorts prefix.

R.