Re: Release process (was Re: DarwinPorts 1.3.1)

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

>> Nevertheless, I wholeheartedly agree with your point about testing  
>> the ports: we need a real infrastructure. In case you didn't  
>> notice, the recent changes to the trace option are exactly  
>> intended for that purpose. With the -t option, you no longer need  
>> to use the union disk image trick you (?) came up with when you  
>> tried to automate the process. Ports cannot write outside the  
>> sandbox at run time. If -t is always used, /opt/local only contain  
>> files copied during the activation phase.
>
> That's a great step along the road, and certainly lighter weight  
> than the union disk image tricks I was playing with (and probably  
> more reliable, given some of the weird interactions between devfs/ 
> volfs and chroot environments I've run into).  However, I hope that  
> you're not just trying to trap writes outside the sandbox, but also  
> reads.  It's only half the problem to make sure that a port is  
> confining itself to /opt/local, we also need to be able to sandbox  
> port builds such that they only find things we've expressly allowed  
> them to find.  Given the presence of, say, libjpeg.dylib, you only  
> want a graphics program to grow jpeg capabilities if it explicitly  
> calls out for libjpeg (possibly in a variant) vs having its  
> configure script stumble across it and say "Hey, I can use that..."

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.

Actually, it currently does its work too well. For example, many  
ports use the ginstall binary from coreutils if coreutils is  
installed. Does it mean that all these ports require coreutils?  
Likewise, base/ refer to bzip2 without using a hard-coded path  
provided at runtime. Consequently, it will use DP's own bzip2 to  
extract bzip2 tarballs or to compress software packages. Trace mode  
reveals all this.

>> Combined with the automatic detection of dependencies (still  
>> option -t), the (almost) full test of all ports can be done in a  
>> much simpler and less expensive way. There are a couple of  
>> additional structural changes to get this working completely (for  
>> example to drop the bin: and the lib: dependencies in favor of the  
>> port: dependency, or include a conflict key to portfiles as you  
>> mentioned recently), but we've never been that close to the goal  
>> software-wise (which is as much I can do as a base/ committer).
>
> Actually, it sounds like both of those goals are achievable by any  
> committer - I wouldn't sell yourself short there.  Even the often- 
> quoted "lack of infrastructure" can be dealt with if we have  
> something worth actually running over the entire ports collection.

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.

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