Date: Wed, 16 Aug 2006 23:42:36 -0700 From: Brian Somers <brian@Awfulhak.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org, =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= <gabor@FreeBSD.org>, cvs-all@FreeBSD.org, Erwin Lansing <erwin@FreeBSD.org> Subject: Re: 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 ... Message-ID: <20060816234236.3428ab08@dev.lan.Awfulhak.org> In-Reply-To: <44E39535.10701@FreeBSD.org> References: <200608041234.k74CYoc1076722@repoman.freebsd.org> <44E389AA.3000003@FreeBSD.org> <44E38E2F.4000005@FreeBSD.org> <44E391AD.3010402@FreeBSD.org> <44E39535.10701@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-developers elided] 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@FreeBSD.org> wrot= e: > Building fully in chroot(8) environment with the help of nullfs is=20 > another obvious solution, yes. In fact we use it in production for 4=20 > years here. >=20 > -Maxim >=20 > G=E1bor K=F6vesd=E1n wrote: > > Maxim Sobolev wrote: > >> Maxim Sobolev wrote: > >>> I think the solution proposed in PR/100555 is overengineered. Why not= =20 > >>> to build temporary binary package as usually and then use chroot(8)=20 > >>> (or -C flag for pkg_install) to install it into DESTDIR environment?= =20 > >>> This would be *much* simpler approach and it won't require modifying= =20 > >>> anything but bsd.port.mk. Putting additional load on port maintainers= =20 > >>> on keeping their ports DESTDIR-clean is too much for such a niche=20 > >>> feature. > >> > >> Just to make clean: what I am proposing is the following course of=20 > >> actions when DESTDIR is defined: > >> > >> 1. Build port as usually. Install it as usually. > >> > >> 2. After usual installation is complete build temporary binary package= =20 > >> out of it and install it into DESTDIR environment. > >> > >> Automating it would require some amount of work, granted, but it would= =20 > >> be one time task, not constant burden on port maintainers. > >> > >> -Maxim > > I don't think it would be good, since: > >=20 > > 1, The package building requires that the package be installed first,=20 > > and we don't want to make the host environment dirty in such way. > >=20 > > 2, We can have a host environment with another set of dependencies. E.g= =20 > > foo depends on php, but we have php5 in host environment, but php4 in=20 > > DESTDIR. The package will be linked against php5 libs then and can't=20 > > work under DESTDIR. > >=20 > > Btw, Kris has an another good solution: > >=20 > > http://lists.freebsd.org/pipermail/freebsd-ports/2006-August/034835.html --=20 Brian Somers <brian@Awfulhak.org> Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060816234236.3428ab08>