Date: Sat, 1 Dec 2001 20:30:04 -0500 From: Alan Eldridge <alane@geeksrus.net> To: FreeBSD Ports List <ports@freebsd.org> Subject: building as non-root Message-ID: <20011201203004.A24482@wwweasel.geeksrus.net>
next in thread | raw e-mail | index | archive | help
WARNING: LONG MESSAGE A question of procedure & philosophy ... To do port builds, I have a local copy[1] (under my $HOME) of the tree I mirror with cvsup. I do builds as 'alane', and then use 'sudo make install' to actually install the port into "production" use. After that, I can create a package with 'make package' without having to regain root privilege in most cases. This reflects my S.O.P. for many years in my work environment on various (mostly Sun) Unices and at home on Linux; by building as non-root, I can both (1) protect myself against an errant Makefile or command except during the install itself, and (2) make sure that there is nothing lurking in the build itself that assumes root privileges. This reflects my belief that nothing in an *application* build should ever require administrative privileges to perform. So far I haven't noticed any failures using this method. Some ports do require administrative privileges to package, because they are packaging files from the live filesystem that not world readable. This brings me to the issue I have with how ports work: to build a virgin package we do not want to package files from the live filesystem. Better yet, we really don't want to install to the live filesystem in the first place. Most GNU automake generated Makefiles support a variable called DESTDIR. If they don't we can fake it with PREFIX. The basic idea is this: PREFIX=/usr/local BUILDROOT=/usr/tmp/$PKGNAME-root ./configure --prefix=$PREFIX make and then either (1): make DESTDIR=$BUILDROOT install or (2): make PREFIX=$BUILDROOT$PREFIX install We can get an install tarball by: cd $BUILDROOT tar zcvf $PACKAGEDIR/$PKGNAME.tar.gz . Yes, this occasionally backfires. Libtool can be most uncooperative in this respect, as it may insist on relinking things (and worse, on some platforms, putting in a runpath with -rpath) during that install step when you're lying about your true destination. Interpackage dependencies can be a PITA when building like this[2]. For a lot of packages, though, this works quite well. In fact, for *most* packages, this general procedure works. Redhat's RPM is based on this installation method, for example. What I don't see, and maybe I just haven't looked in the right places, is a framework in the BSD makefiles that support this kind of build and install. If there's something in there that supports this kind of "fake root" build and install, I'd like to know what variables and make targets to look for. If it's just not there at all right now, well, I guess I have a project to consider, and I'd like any constructive thoughts (please forget I mentioned RPM before replying) that you may have about this issue, and whether it is doable without overhauling the existing make framework. Notes: [1] It's not a copy. It's a link farm. Directories in which I'm building are real directories with real files; others are links into the cvsup ports tree, to which I cannot write. To build a new port, I replace its link with a copy of its ports dir. [2] I probably built KDE 2.2.x > 150 times since this June. Every time a C++ interface changed in kdelibs, I had to build kdelibs, install it, and then go back and build the rest of the pile. No real way around that. Does it suck? Usually, 'cause you don't find out that kdelibs changed in an incompatible way until you're into the build of kdebase or even later. Is there a fix? Not an easy one, certainly. -- Alan Eldridge #include <cstdlib> free(sklyarov); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011201203004.A24482>