Re: Release process (was Re: DarwinPorts 1.3.1)

On Aug 2, 2006, at 7:32 PM, Paul Guyot wrote:

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

Hmm, I still think we're somehow talking past one another.  I'm NOT  
suggesting that we deny read()s - if you look at my last 2 or 3  
messages again, you'll see that it's open(2) (and, by inference, access 
(2) and stat(2)) I think we should block.  I'm not worried just about  
reads, it's the probes that need to be defeated.

The reason it's so important to do that is due to the fact that not  
all configure probes are going to necessarily read data from files.   
Some will simply attempt to open or stat the file and, if it exists,  
do some conditional behavior based upon that fact.  If you don't  
actually control the namespace, you're not really controlling  
anything, and you only control the namespace by making file access  
attempts *fail*.   Again, your mental model should be the chroot build  
environment.  Can you open a file outside the chroot?  No.  Can you  
stat a file outside the chroot?  No.  If trace mode cannot fully  
simulate a chroot environment then we'll be soon back to using disk  
images again because other projects have already proven that you NEED  
this level of isolation in order to truly guarantee your results.    
We're not the first people to do this - we're probably closer to the  
last - and we should learn from the experience of other package  
generation projects.

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

I agree, though I think we do need the "conflicts" and "broken"  
keywords we've discussed earlier.  If we have those, then we can flag  
known build issues and avoid spamming people without cause (which will  
make people more willing to pay attention to the failure reports).

> * modify base/ to introduce virtual ports for stuff provided by  
> MacOS X.

Yep.

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

That would be great, though not strictly necessary to get to a package- 
oriented world.  Having port -> port dependencies should be enough to  
get us to:

> * implement binary packages. These require all the previous changes  
> (working upgrade procedure, enhanced dependency code).

- Jordan