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