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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
