On Wed, Dec 2, 2009 at 5:01 AM, Ciprian Dorin, Craciun <[email protected]> wrote: > 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=82443e00597b0db5a7eadea4886e22b373ac373b > 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
