Date: Sun, 2 Dec 2001 06:44:25 +0300 (MSK) From: "."@babolo.ru To: alane@geeksrus.net (Alan Eldridge) Cc: ports@FreeBSD.ORG Subject: Re: building as non-root Message-ID: <200112020344.GAA10704@aaz.links.ru> In-Reply-To: <20011201203004.A24482@wwweasel.geeksrus.net> from "Alan Eldridge" at "Dec 1, 1 08:30:04 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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?=<something[3]>
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 <cstdlib>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112020344.GAA10704>