Re: Release process (was Re: DarwinPorts 1.3.1)

Le 3 août 06 à 10:09, Jordan K. Hubbard a écrit :

>
> On Aug 2, 2006, at 3:17 PM, Paul Guyot wrote:
>
>> Are you basically saying that trace mode should be used in  
>> production code to do the equivalent of --without-X in configure  
>> and enforce it during build and install phases?
>>
>> I was only thinking about using it for automatic testing. There  
>> are several reasons for not requiring its use in production code.  
>> For example, trace mode slows the installation process  
>> significantly. Besides, the mode isn't completely protected from a  
>> port that could get rid of it, for example by unsetting global  
>> variables. Finally, some dependencies cannot be detected because  
>> they only happen at runtime.
>
> I don't think there's any real distinction between "production  
> mode" and any other mode going forward.   End-user should (and want  
> to) be using packages.  Packages should be built by the DP project  
> on a regular basis for its users.  Building packages we can trust  
> will require using trace mode to sandbox builds.
>
> The only other people I would expect to be building stuff would be  
> the limited number of Portfile authors, and they'll also want to  
> use trace mode in their development process (at least at the  
> validation stage) to ensure that the Portfile is really correct.   
> End-users only build ports today because there are no packages, not  
> because end-users are good at building stuff (they're not) or enjoy  
> the process (they don't).  That makes the notion of a "faster  
> production mode" kind of irrelevant.

OK. Your proposition makes sense. The main difference I can see  
between failing on read and reporting on read is to allow port  
developers to not use the --without-X configuration option when they  
develop variants (in some cases, at least). As long as the binary  
package is built on a box with the trace mode, we can always make  
sure that the port doesn't refer to anything that is undeclared, and  
therefore forbidding read operations isn't required. Besides,  
preventing reads can only be implemented once the trace mode is the  
default one (and DP delivers binaries). Performance-wise, this change  
should be implemented by pushing more code inside the native library  
(instead of using the pipe and the Tcl thread) and this will both  
yield an increase of speed and a better stability (did I mention that  
trace mode reveals a hard to reproduce concurrency bug in native code  
-- Tcl or Pextlib?).

I think it's time the discussion be transformed into a realistic  
roadmap considering the human and hardware resources we have.

I can see four steps:
* implement a test system relying on trace mode. This system would  
try to compile the files and display the result on a web page or  
possibly spam the port authors. This requires little or no change in  
the base/ code. Actually, there are two changes that can be  
implemented while the tests are already running: a conflict  
dependency edge and a fixed upgrade code, disabling ports that a port  
dependended on.
* modify base/ to introduce virtual ports for stuff provided by MacOS X.
* re-design the dependency engine to use a provides/requires  
relation. Two ports can provide the same feature. There has been  
plenty of suggestions for this bit on the list.
* implement binary packages. These require all the previous changes  
(working upgrade procedure, enhanced dependency code).

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