cvs commit: ports/Mk bsd.emacs.mk bsd.gnome.mk bsd.mail.mk
bsd.openssl.mk bsd.port.mk bsd.port.subdir.mk bsd.python.mk
bsd.ruby.mk bsd.scons.mk ports/Tools/scripts security-check.awk
ports/databases/p5-DBD-Oracle Makefile ports/databases/p5-sqlrelay ...
brian at Awfulhak.org
Thu Aug 17 06:42:43 UTC 2006
Interesting... I use nullfs as part of our build system here.
I found that it's performance is appalling when pushed a
little (running two builds on one machine, each with two
nullfs mounts, two devfs and two procfs mounts gives a build
time of 4.5 hours whereas a single build will finish in 1.5
hours). I've seen >6 hour builds on a loaded box - only
attributable to nullfs.
That coupled with the statfs struct size limitation limiting
mount paths to 80 characters makes nullfs difficult to use in
any automated manner at best.
Of course the resulting build consistency in terms of environment
is worth it's weight in gold, as we distribute binary patches and
are keen to avoid needless updates.
On Wed, 16 Aug 2006 14:59:17 -0700 Maxim Sobolev <sobomax at FreeBSD.org> wrote:
> Building fully in chroot(8) environment with the help of nullfs is
> another obvious solution, yes. In fact we use it in production for 4
> years here.
> Gábor Kövesdán wrote:
> > Maxim Sobolev wrote:
> >> Maxim Sobolev wrote:
> >>> I think the solution proposed in PR/100555 is overengineered. Why not
> >>> to build temporary binary package as usually and then use chroot(8)
> >>> (or -C flag for pkg_install) to install it into DESTDIR environment?
> >>> This would be *much* simpler approach and it won't require modifying
> >>> anything but bsd.port.mk. Putting additional load on port maintainers
> >>> on keeping their ports DESTDIR-clean is too much for such a niche
> >>> feature.
> >> Just to make clean: what I am proposing is the following course of
> >> actions when DESTDIR is defined:
> >> 1. Build port as usually. Install it as usually.
> >> 2. After usual installation is complete build temporary binary package
> >> out of it and install it into DESTDIR environment.
> >> Automating it would require some amount of work, granted, but it would
> >> be one time task, not constant burden on port maintainers.
> >> -Maxim
> > I don't think it would be good, since:
> > 1, The package building requires that the package be installed first,
> > and we don't want to make the host environment dirty in such way.
> > 2, We can have a host environment with another set of dependencies. E.g
> > foo depends on php, but we have php5 in host environment, but php4 in
> > DESTDIR. The package will be linked against php5 libs then and can't
> > work under DESTDIR.
> > Btw, Kris has an another good solution:
> > http://lists.freebsd.org/pipermail/freebsd-ports/2006-August/034835.html
Brian Somers <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour ! <brian at FreeBSD.org>
More information about the cvs-ports