Hi,
One of the things I really like about the FreeBSD ports infrastructure
is that, when you go to 'make install' a port, and you aren't root, it
will automatically call 'su' for you.
Since I build DragonFly's world as a regular user (it's less dangerous
than developing as root,) I figured it would be nice to have the same
functionality there, since I often forget to su to root before
installing.
A diff to accomplish this can be found here:
http://catseye.webhop.net/DragonFlyBSD/patch/Makefile.inc1.diff
It was adapted straight from ports/Mk/bsd.port.mk. However, I think it
needs some work. There are three main issues.
One is that the code sequence
..if ${UID} != 0 && !defined(INSTALL_AS_USER)
@echo "===> Switching to root credentials for '${.TARGET}' target"
@cd ${.CURDIR} && ${SU_CMD} "${MAKE} ${.MAKEFLAGS} ${.TARGET}"
@echo "===> Returning to user credentials"
..else
....is repeated four times in the patch. This is exactly the sort of
thing that should be abstracted into a procedure - except I'm not sure
how to do that with make(1), which doesn't have procedures (that I'm
aware of.) I'm sure there's a way to hack it up - but that raises the
question of what's uglier. At least the cut-and-pasted version would
have the advantage of having fairly obvious behaviour.
The second issue is that ports Makefiles have a convention of having
variables for almost every command name, whereas the base Makefiles
don't. I added a ${SU_CMD} variable, but I didn't bother to add
${ECHO_MSG} (since other messages in Makefile.inc1 were done with a
plain 'echo') or ${ID} (since it was only used once.) If the above code
sequence was abstracted out, it might not make sense to have ${SU_CMD}
either... I gather that the base system has less need to play games with
command names than the ports tree does.
The third issue is that this only works for "top-level" targets like
"installkernel" and "installworld". If you manually go and do something
like "cd /usr/src/usr.sbin/blah && make all install" as a regular user,
this patch won't catch that. I'll look into a patch to do that as well,
but I get the impression that the wrapping the ultra-generic "install"
target in this way would be trickier (i.e. you wouldn't want it to su
for each individual subdir, asking you for the root password each time)
Anyway, feedback on this would be very appreciated! :)
Thanks,
-Chris