Re: Release process (was Re: DarwinPorts 1.3.1)

Le 2 août 06 à 17:29, Jordan K. Hubbard a écrit :

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

I'm not sure I understand exactly everything you suggest.

You first mention turning reads into hard errors. How does it change  
anything? An automatic build system can still report the warnings  
about the undeclared dependencies and call for further inspection to  
fix the port up and then either uninstall the port considering it's a  
failure or just proceed on activating it, allowing to test ports that  
depend on it. Ideally, we should test ports with as many other ports  
installed to make sure they don't test for the existence of other ports.

I simply don't understand the bit about "the trigger to go off and  
build those things first", unless you refer to the existing  
dependency engine of DP.

You also mention extending the checks to files from the system  
because of problems introduced by MacOS X updates. It's a good idea.  
However, I think that if we can first get an automatic process that  
tests ports on a pristine OS X install for a given version of OS X,  
it would already solves most of the testing problem and help DP  
developers to fix ports.

Testing what is installed by MacOS X by checking the receipts can  
happen but I think it should be coupled with the notion of virtual  
ports that is yet to be introduced in DP to replace the lib:  
dependency. For example, either use X11 from DP or the one from  
Apple, defined as the series of files listed in the X11User & SDK  
receipts. Considering this a requirement for automatic testing might  
unfortunately postpone the tests to the day we will have a new  
dependency engine.

Paul
-- 
Ministre ultraplénipotentiaire en disponibilité.
Mobile. Sans baignoire fixe.
http://www.kallisys.com/
http://www-poleia.lip6.fr/~guyot/