Mark Rosenstand schrieb:
Actually I'm working on a build system that allows for building each package in a completely clean environment (only base + the package's dependencies, the chroot/sandbox is wiped after each build.)
This helps to ensure that packages - have the correct dependencies, since the build will fail if they aren't installed at compile time - are less influenced by the host system, so the packages should be faily distributable - are always compiled against the wished libraries, ignore autoconf's "link-against-everything-avaiable" logic
Obviously it will take a bit longer to prepare the sandbox for each build, but the base system could be a single tar archive (or some hack like hardlinks + COW or (f)unionfs.
Real support for fakeroot is obviously also planned (running the entire compilation in a LD_PRELOAD-hacked environment is a bit insane, only the "make install" and final tar'ing should be fakerooted.)
when building own ports I found software packages which are doing "evil things" even in the make step, not only in make install. and there are some packages without the classical ./configure | make | make install available - so fakerooting everything should be considered. but i like your overall idea and can provide an even simpler approach, almost without any coding work, using a vserver: - it is a matter of seconds to clone an installed base vserver - fire it up and pkgadd the dependencies for the port in question - optional: for large/common dependencies, clone again - run the actual build on that almost unmodified system - the results can be reportet - overall system modifications during the build are also trivial within the vserver, other conditions can be easily modified: - no network/dns at all (some ports stupidly relay on that) the base vserver could be a regulary bootstrapped installation (based on jaegers crux-2.2-latest.iso for example), or, perhaps even better, a base crux system starting from the last iso release and updated regulary. or both. this way perhaps more hidden build problems which only occur on updated or fresh installs can be detected. keep me informed if you do further steps or like my approach. i am very interested in such a port verification because i mainly use crux as vserver guest os, and this could help improve port quality even for this scenarios. in mid-term, i could also provide vserver-infrastructure. sincerly, cohan (martin koniczek)