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 ...

[Maxim Sobolev]

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.

-Maxim

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
>