PortGroup directory hierarchy/priority
cal at macports.org
Mon Apr 4 13:54:22 PDT 2016
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
> > 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.
More information about the macports-dev