On Wed, Dec 2, 2009 at 5:01 AM, Ciprian Dorin, Craciun
Hello all!
For some time I was struggling in creating (for myself) a "sterile" environment for package building purposes. (I want to build some custom packages for a custom lightweight distribution.) And in what follows I would like to share my experience with pacman / makepkg developers in such a "sterile" environment.
By "sterile" I mean the following: * clean, uncontaminated packages: freshly installed by pacman from a repository without my intervention; (if I would use my ArchLinux installation, some packages (compiler, libraries, etc.) would be configured to my like, and thus it could create a non-repeatable build); * minimal package installation base: only the packages that have been clearly declared as dependencies in PKGBUILD should be installed (of course with their dependencies); * I need the assurance that configure and make scripts of different packages pick up the right build tool-chains (for example for cross-compiling);
As such, I've decided of the following: * prepare a UML (User Mode Linux) kernel, that shall provide me with a clean build Linux environment; (this could of course be replaced with a Vserver instance;) * prepare a (static linked) BusyBox with all the tools built in; (this shall be installed outside of the normal PATH, to be sure it's not picked up by the configure and make scripts;) * prepare a (static linked) Bash (installed outside the normal PATH); * when running makepkg, I'll set the PATH=/.workbench/tools/busybox/bin:/.workbench/tools/bash/bin; * but when inside the PKGBUILD I'll reset the PATH=/usr/local/bin:/usr/bin:/bin:etc....
Now my experiences with makepkg in such an environment: * it seems it works without too much fuss with the commands provided by busybox, except; * if one has declared of using only MD5 sums (most of the packages do this), it insists on using `openssl dgst` to create them; See commit b8a66d68593d1f267c3bb8cd8943724711626903 as Allan pointed out, which was to fix FS#10530. You'd be reverting that which is not really what we want.
* it insists on using file tool to identify the file type; Allan got this one. (FS#6246)
* it insists on using bsdtar to untar the tar archives; bsdtar is a hard dep of pacman and makes our work in makepkg a ton easier. It works for all sorts of archives and I would have a real hard time seeing why we should step away from it.
* it breaks if it's not able to chown the source tree; (this happens as inside UML I'm root, but outside UML the file system is owned by a normal user (the root filesystem of UML is exported by using hostfs)); Sounds like UML needs something like fakeroot?
So, as you can see nothing that can't be solved with some minor corrections.
As such, if the community is interested I could provide some patches that allow makepkg to: * use md5sum instead of openssl for MD5 checksums; * use normal tar if bsdtar is not available; * base the file-type decision on file (if available), or on extension (if file is not available); * ignore errors for chown of source tree; (of course with a warning;) * provide a way to customize the path of the pacman tool; (maybe this has already been done); Getting close here, see http://projects.archlinux.org/pacman.git/commit/?id=82443e00597b0db5a7eadea4...
Also it would be nice (though painful) to allow the customization of paths for all external (non Bash functions) tools. For example: instead of calling mv, one should call "$mv", which should default to mv="${MV:-$( which mv )}" (that is if the variable MV is not defined then fallback on using the mv tool found in the PATH).
A unix-y system without mv? This seems overkill to me. I highly doubt all of our packages have a makedepend on coreutils anyway. I can see why a lot of these things seem appealing for your setup, but the problem is a lot of them are in contrast to portability issues we've had in the past and resolved. -Dan