CRUX distfile bbackup server

Martin Koniczek martin at koniczek.de
Thu Sep 7 11:05:31 UTC 2006


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)




More information about the CRUX mailing list