Some work/cleanup here would probably be desirable. I'm committing them
now to give others the ability to reproduce these package splits and help
with making these scripts better. The README should have some more
documentation in the future.
A better solution to the package set size problem would be to teach
sysinstall to ask for the CD on which a particular package is when it
needs to add it, but for now this will do.
Requested by: murray
Written by: steve
Discussed with: steve, kris (some time ago)
* Add a trap handler to try and clean up the build if it is interrupted
by a signal (one problem with the previous version is that package builds
whice are interrupted by ptimeout because they are stuck, leave their
working files lying around in the chroot).
* Switch to NFS v3 mounts instead of v2
* Autogenerate the version string to report in uname within the chroot,
based on the version string in the head of the CVS branch being built.
* Copy packages via cp from the NFS mount, not scp.
* Require an additional <tmpdir> argument so the client knows where its
temp directory is.
* Mount the portbuild directory readonly via NFS, and copy files that
way instead of via scp, which has too much overhead
* Don't assume the script will be called from the ports directory
* Use buildenv to set environment variables
* Set LOCALBASE and X11BASE to dummy variables to prevent the ports tree
from picking up packages installed on the host system, and patch up
the generated index at the end
operations in one central place, instead of doing them piecemeal all over
the place. This also includes the ability to customize settings per
port branch (e.g. XFREE86_VERSION)
Also, instead of hardcoding values of OSVERSION and OSREL which are going
to get forgotten again, pull them out of the source tree in ${branch}/src
so they track the head of the branch.
tangled up.
* Sort the environment variables so that all of the commented out ones
are grouped together
* Reverse sense of NOPLISTCHECK -> PLISTCHECK, since it's not an option
we want enabled by default (it causes too many build failures). This
was too easy to forget when building packages 'by hand' using the parallel
makefile.
* Copy across UNAME_VERSION into the chroot area so that uname inside the
chroot reports the desired version
* Shorten timeout period from 12 hours to 4 hours to avoid delaying the builds
unnecessarily.
* Reverse sense of NOPLISTCHECK -> PLISTCHECK, since it's not an option
we want enabled by default (it causes too many build failures). This
was too easy to forget when building packages 'by hand' using the parallel
makefile.
we want enabled by default (it causes too many build failures). This
was too easy to forget when building packages 'by hand' using the parallel
makefile.
* Display correct pathnames in build progress messages
* Add a -nocdrom option to avoid the (time-consuming) clean-for-cdrom-list
target
* Remove x11/XFree86 from dummyports since we don't want to use an old
stale version of the package which never gets rebuilt
* Add comments noting that we should check for CVS conflicts in the cvs
update scripts and exit gracefully.
we want enabled by default (it causes too many build failures). This
was too easy to forget when building packages 'by hand' using the parallel
makefile.
* Don't require the script to be called from inside the branch directory;
follow standard practise and pass the branch to build as an argument.
* Populate the chroot with the BSD.local.dist mtree file
* Add whitespace for readability, and sprinkle liberally with comments
* Comment on some inscrutable parts of the script which were presumably
put there to work around a (perceived) problem, but which I can't
understand.
of just proclaiming "error(s) occurred". This should immediately identify
which port is causing the build to break (although it's a bit of a verbose
solution).
* Update the list of ports which takes a long time to build.
* Don't use a single ports collection for every port build, indirect through
${pb}/${branch}/ports so we can have different ports collections for
each branch. Add -noportscvs option to prevent cvs update of ports
collection.
* Remove 3.x as a valid branch, add 4-exp for the 4.x experimental builds
used for testing bsd.port.mk patches
* Update usage information
decide machines which should be handed new jobs. Also, at some point someone
added a note about a possible bug in the reportload script which causes
this one to fall over.
down to user support flaws in the FreeBSD ports system. The flaw in question
is related to the fact that dependencies are often "chained", which allows to
simplify maintenance of ports with large number of implied dependencies (a la
Evolution, Nautilus, you-name-it). Dependency chaining it's not a problem by
itself, but the fact that when building or installing a port the system doesn't
check chain integrity - it's only checks that dependencies explicitly
specified in port's Makefile are satisfied, which opens wide window for
various hard-trackable problems when one or more links in the middle of the
chain missed.
The idea behind the tool is quite simple - it should be executed right after
main dependency checking procedure, two times for each build - check build-time
chain before building the port (pre-pre-extract) and check run-time chain
before installing the port (pre-pre-install). When executed, the tool checks
integrity of the specified chain (build-time, run-time or both) and reports all
errors, both fatal (dependency isn't installed) and non-fatal (dependency is
installed, but different version).
I've wrote this tool mostly to simplify maintenance of the GNOME ports, but
it doesn't contain anything GNOME-specific, so that it could be used in the
other parts of tree as well.
As an example I've added GNOME_VALIDATE_DEPS_CHAIN knob into bsd.gnome.mk (off
by default), which enables automatic chain validation for all ports that
USE_GNOMELIBS. This is a bit hackish, because I've used pre-extract and
pre-install targets - what we probably need is a generic way to plug various
custom tasks specified in bsd.xxx.mk (where xxx is kde, gnome, python, etc.)
into various parts of the build process (something like {pre,post}-pre-foo,
{pre,post}-post-foo springs into my mind).
The code is quite raw, so that I would appreciate any bug reports, patches,
suggestions, constructive critiquie and so on.
