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
Makefile ports/databases/p5-sqlrelay ...
sobomax at FreeBSD.org
Wed Aug 16 22:00:12 UTC 2006
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
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
>> 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.
> 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:
More information about the cvs-ports