PortGroup directory hierarchy/priority
cal at macports.org
Fri Apr 8 12:03:29 PDT 2016
On Wed, Apr 06, 2016 at 10:48:00AM +0200, René J. V. Bertin wrote:
> > 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.
We don't need to have control over each minor detail, the control we
currently have is more than enough to get builds reproducible (even
though we may need one hack or the other, like DYLD_INSERT_LIBRARIES).
> > 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
No. Some problems are still to be solved, like how to sync a
sqlite3-based pre-generated portindex from a server. I had even started
an sqlite3-based portindex a while back, but the project died. It's
possible, but needs manpower and refactoring.
> I mean runtime cost, implementation of something like that seems like
> a nice summer project for someone.
Unfortunately due to the number of places where the portindex is used
(without abstractions) across MacPorts base, I fear this may be a bigger
project than a summer.
More information about the macports-dev