Ticket #14796 (pike): please commit

[Jordan K. Hubbard]

On Mar 31, 2008, at 4:32 AM, Guido Soranzio wrote:

> We are in serious need of:
>
> 1. An open repository where to exchange precompiled archives in
>   order to avoid the lengthy compilations of the dependencies.

One might argue instead that we are in serious need of a binary  
packages collection, any package from which could/should be detectable  
by the dependency checking machinery and, if suitable, used in lieu of  
a build.   That would kill two birds with one stone - make development  
easier and also give end-users what they've wanted since the project  
was announced.

> 2. A buildbot on a central server which automatically builds
>   and tests the proposed portfiles in a chroot'ed environment.

That would be nice (and, given a centralized package building/hosting  
structure, would also give us this for all the existing ports as a  
side-effect), but the project has also claimed to want such a thing  
for a long time without actually being motivated enough to create the  
software for driving such a buildbot, so the actual need remains  
debatable.   In lieu of this possible future development, I think it  
would be useful enough just to be able to turn any individual machine  
into a "buildbot" for short periods of time since disk space and CPU  
horsepower are getting cheaper and cheaper and I doubt even 20% of Mac  
users these days really push their machines to the limit.   It could  
be something as simple as this to start:

port chroot-create /tmp/mychroot [optional target describing flags]
while <my-port-doesn't-work>; do
	port chroot-exec target portname|portfile
	<edit>
done
port chroot-destroy /tmp/mychroot

The mechanics of chroot-create wouldn't even be particularly complex,  
but creating an effective chroot environment on MacOSX is a little  
harder than on less dynamically linked/less complex systems like Linux  
and FreeBSD and requires knowledge of what files to copy in as well as  
what specialized filesystems to mount in order to keep, among other  
things, Carbon apps from blowing up (see macports/base/portmgr/ 
packaging/buildall.sh for an earlier attempt to do this for each port  
in the collection as a regression test).  The chroot-destroy command  
would, of course, be responsible for unmounting stuff and properly  
nuking the chroot environment again.

Either way, you've provided a nice abstraction boundary for the  
developer and can refine the definition of "chroot" as various edge  
cases are found without having to disseminate updated instructions to  
everyone.  I probably updated my chroot definition about 20 times  
while I was creating that buildall.sh script I just mentioned and I  
still don't think I got it totally right in terms of "minimum  
functional footprint."

> 3. A "testing" branch for the beta-testers who would like to help
>   transitioning to development releases without breaking
>   the main trunk (i.e. Gnome 2.22, Python 3.0, KDE 4.0, ...).

We could do that, or we could do what many other projects seem to do,  
which is to get most people living on the -stable branch, where the  
releases also come from, and get trunk back to the purpose of doing  
just that sort of testing.  Developers shouldn't be so terrified of  
breaking trunk, assuming that they're also willing to be responsible  
enough to quickly fix what they break (and, if they don't, there's the  
back-out rule).

- Jordan