Re: Release process (was Re: DarwinPorts 1.3.1)

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

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

Sorry, I oversimplified. I was indeed referring to blocking reads by  
blocking open(O_RDONLY) (and stat/opendir/exec) versus blocking  
writes by blocking open(O_RDWR | O_WRONLY) (and mkdir/rename/rmdir/ 
unlink).

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

This is where I disagree. Do you know any package generation project  
based on library injection and trapping calls?

Library injection gives enough granularity to be able to independently:
- detect what the package refers to
- prevent the package from doing dirty things
- prevent the package from referring to things

While chroot doesn't provide this granularity.

I maintain that the third item isn't required at all. It changes some  
details, but a robust package generation tool can only be based on  
the first two items.

On the box building packages, it's perfectly fine if a port A refers  
to port B while the dependency isn't declared in the portfile. We  
only need to add the dependency rule because the box installing  
packages should install port B before installing port A. Preventing  
port A to detect port B either reduces the features of the package of  
port A (it could take advantage of port B) or will make it fail (if a  
node fails in the dependency graph, the connected nodes cannot be  
built either).

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

The provides/requires relation is just there to cope with virtual  
port and to replace the lib:/path:/bin: requires condition. Only  
having "port:" or port -> port dependencies as you write either mean  
we'll install DP's X11 on the boxes or we drop the X11 port.

Besides, a major rewrite of the dependency engine is required to get  
binary packages working because we need the relevent subgraph of the  
dependency graph to be recorded in the binary package and we need to  
make use of it. If the binary package A was linked against DP's  
libreadline 5.1 and user has libreadline 5.0, we need to upgrade  
libreadline first before installing package A.

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