PortGroup directory hierarchy/priority

[Clemens Lang]

Hi,

On Mon, Apr 04, 2016 at 08:17:55PM +0200, René J.V. Bertin wrote:
> > > There's only one way to enforce the reproducible build principle
> > > all the way, and that's to remove the whole possibility of
> > > building from source so that users can only install official,
> > > binary packages.

> > No, that's (a) not true and (b) actually prevents one of the goals

> I can see (b) but not (a)?

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

> > Sure, let's assume you change the github 1.0 PortGroup, because you
> > need an additional feature… that could change how other ports fetch,
> > and thus the source that is being built be other ports.
> 
> […]
> 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.

> > The whole installation idea does not work with the current codebase.
> > If a PortGroup changes, the information in the PortIndex needs to be
> > updated, but the PortIndex uses the modification date of Portfiles
> > to determine whether the information is current.
> 
> So no PortGroup is taken into account?

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

> > You can not change how a port behaves without touching the Portfile.
> > See the above rationale on the PortIndex.
> 
> And that doesn't apply to copying PortGroups manually into _resources?

That also applies to copying PortGroups manually into _resources.

> > I think most of this discussion could be solved by merging your
> > changes into the main port tree, couldn't it? I think that's what we
> > should be
> 
> Yes, that's true. There is testing underway to that end, but only 2 or
> 3 port developers have stepped up to help here, and there's barely any
> activity on the corresponding trac tickets.

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.

-- 
Clemens