Re: Release process (was Re: DarwinPorts 1.3.1)

On Aug 2, 2006, at 12:36 AM, Paul Guyot wrote:

> There is a little misunderstanding here.
> I mentioned testing base/, not testing in general. The 1.3.x fiascos  
> were caused by the lack of testing of HEAD base/ code.

OK, sorry I misunderstood the scope of what your suggestions were  
aimed at.

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

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

- Jordan