From owner-freebsd-ports Sat Dec 1 19:37:54 2001 Delivered-To: freebsd-ports@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id 76F1037B405 for ; Sat, 1 Dec 2001 19:37:43 -0800 (PST) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id GAA10704; Sun, 2 Dec 2001 06:44:25 +0300 (MSK) Message-Id: <200112020344.GAA10704@aaz.links.ru> Subject: Re: building as non-root In-Reply-To: <20011201203004.A24482@wwweasel.geeksrus.net> from "Alan Eldridge" at "Dec 1, 1 08:30:04 pm" To: alane@geeksrus.net (Alan Eldridge) Date: Sun, 2 Dec 2001 06:44:25 +0300 (MSK) Cc: ports@FreeBSD.ORG From: "."@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alan Eldridge writes: > WARNING: LONG MESSAGE Answer is longer :-) > 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. Some broken ports as modula3* do build on install. > 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. May be can't. For examlpe such install command sed -e "s|%%PREFIX%%|${PREFIX}|g" infile > ${PREFIX}/path/outfile where only one ${PREFIX} must be prefixed with DESTDIR > The basic idea is this: > > PREFIX=/usr/local > BUILDROOT=/usr/tmp/$PKGNAME-root IMHO better PREFIX=/usr/local TMPDIR?= BUILDROOT=${TMPDIR}/$PKGNAME-root and name BUILDROOT is not exact Why different BUILDROOT for each package by default? May be use DESTDIR as is and IF want separate packages in own roots do something similar to make DESTDIR=${TMPDIR}/${PKGNAME}-root install ? > ./configure --prefix=$PREFIX > make > > and then either (1): > make DESTDIR=$BUILDROOT install > > or (2): > make PREFIX=$BUILDROOT$PREFIX install Not this way > 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. There no need for "fake root" build (do you want to use "fake root" built package with a real root?) but there is some support for "fake root" install: grep DESTDIR * bsd.port.mk:LOCALBASE?= ${DESTDIR}/usr/local bsd.port.mk:X11BASE?= ${DESTDIR}/usr/X11R6 bsd.port.mk:LINUXBASE?= ${DESTDIR}/compat/linux but it is not right. Example (TMPDIR=/tmp/babolo): 1cicuta/usr/ports/sysutils/pib(4)>make DESTDIR=$TMPDIR install FORCE_PKG_REGISTER=yes ===> Installing for pib-1.2 ===> pib-1.2 depends on executable: wish8.2 - found Warning: not superuser, you may get some errors during installation. Warning: not superuser, can't run mtree. You may want to become root and try again to ensure correct permissions. /bin/mkdir -p /tmp/babolo/usr/local/lib/pib install -c -o root -g wheel -m 555 /tmp/babolo/usr/ports/sysutils/pib/work/pib-1.2/*.tcl /tmp/babolo/usr/local/lib/pib install: /tmp/babolo/usr/local/lib/pib/pib.tcl: chown/chgrp: Operation not permitted *** Error code 71 Stop in /usr/ports/sysutils/pib. *** Error code 1 Stop in /usr/ports/sysutils/pib. *** Error code 1 Stop in /usr/ports/sysutils/pib. 1cicuta/usr/ports/sysutils/pib(5)>su2 0cicuta/usr/ports/sysutils/pib(1)#make DESTDIR=$TMPDIR install FORCE_PKG_REGISTER=yes ===> Installing for pib-1.2 ===> pib-1.2 depends on executable: wish8.2 - found /bin/mkdir -p /tmp/babolo/usr/local/lib/pib install -c -o root -g wheel -m 555 /tmp/babolo/usr/ports/sysutils/pib/work/pib-1.2/*.tcl /tmp/babolo/usr/local/lib/pib install -c -o root -g wheel -m 444 /tmp/babolo/usr/ports/sysutils/pib/work/pib-1.2/libTkSteal.so.2* /tmp/babolo/usr/local/lib/pib /bin/ln -fs /tmp/babolo/usr/local/lib/pib/pib.tcl /tmp/babolo/usr/local/bin/pib ------------^^^^^^^^^^^^ ===> Generating temporary packing list ===> Registering installation for pib-1.2 -------^^^^^^^^^^^ 0cicuta/usr/ports/sysutils/pib(2)#l /tmp/babolo/usr/local/bin/pib 0 lrwxr-xr-x 1 root wheel 37 2 ΔΕΛ 06:02 /tmp/babolo/usr/local/bin/pib@ -> /tmp/babolo/usr/local/lib/pib/pib.tcl 0cicuta/usr/ports/sysutils/pib(3)# I do not know, what to do with "Operation not permitted" with install whithout root privileges > 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. I'd like this functionality. For another aims. I do a lot of build/install for jails. > 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. I use original /usr/ports, nfs mount read only from /usr/ports server. With strings PACKAGES=${TMPDIR} WRKDIRPREFIX=${TMPDIR} MAKEOBJDIRPREFIX=${TMPDIR} in my /etc/make.conf it works as need for me exept about 2 broken ports puts Makefile.inc in ports source tree instead of build tree. and about 4 ports need TMPDIR?= ${WRKDIR}/tmp change for TMPDIR= ${WRKDIR}/tmp or similar > [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. [3] I always use /tmp as default if TMPDIR is not defined bacause of I always establish /tmp as separate file system with different than /var (/var/tmp) /usr (/usr/tmp) so on. See mkinittmpdir (PR bin/18275). > -- > Alan Eldridge > #include > free(sklyarov); > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message PS I count now 7 ports which puts Makefile.inc in source tree. Grows. Too bad. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message