Re: Release process (was Re: DarwinPorts 1.3.1)

On Aug 2, 2006, at 1:17 AM, Paul Guyot wrote:

> The trace mode doesn't prevent reads but it associates them with  
> ports the software being built may refer to. In other words, it  
> automatically detects dependencies (and then compares the result  
> with what is declared in the Portfile). Consequently, if a software  
> detects and chooses to use libjpeg from DP but the jpeg variant  
> isn't selected and therefore the port doesn't explicitly depends on  
> the jpeg port, then the trace mode will report it.

OK, I imagine a "trace report" could be turned into a hard error, but  
this still implies that the builder machine will have to be very  
carefully sanitized so that junk on the builder does not creep into  
the builds (or cause trace mode to report errors).  It would be better  
if you could simply use your dyld interposing to cause the open()s for  
things outside the declared dependency list to simply fail.  That is  
to say that if a Portfile has:

depends_port 	foo 1.0
depends_port	bar

Then the system should find manifests for foo and bar and add them to  
the "approved list" of opens.  Anything else (that's not also on the  
approved system base bits list) should simply fail.  If foo and bar  
aren't built yet, that's also obviously the trigger to go off and  
build those things first.

I truly believe that's the only way we're ever going to catch mis- 
specified Portfiles and also prevent updates to MacOSX from causing  
unanticipated behavior (at least, not until we decide we're now going  
to track MacOSX 10.x.y and update the manifests appropriately).  This  
happens all the time, such as when projects like libxml2 or zlib  
entered the system namespace and it was later determined that we'd be  
better off forcing various ports to depend on the DP versions rather  
than using the system versions.  If /usr/lib/libxml*.dylib weren't in  
the base system manifest in the scheme above, the open would fail and  
the dependency on DP's libxml2 would be forced (or found not to be in  
the Portfile, in which case that can be fixed).

> It's exactly what I meant. Committers don't have a box around on a  
> fast and reliable Internet connection having nothing better to do  
> than building all ports to test them all (at least I don't). I'm  
> glad to read that you would provide us with that if the software  
> part gets completed. Thanks.

That offer has been open for some time. :-)

- Jordan