Stefan Winter wrote:
The idea is that make install is not supposed to touch my production config in any way. I don't want it to generously add directories without me knowing.
Honestly, the simplest might be to edit Make.inc, at the top where it defines raddbdir and modconfdir: ifeq "$(raddbdir)" "" raddbdir = ${sysconfdir}/raddb modconfdir = ${sysconfdir}/raddb/mods-config endif Then, do: $ ./configure ... $ make $ make -Draddbdir=/tmp/garbage install All of the raddbdir stuff will get installed to the /tmp/garbage directory. The binaries will be built with the correct paths, and installed in the correct locations.
It was easy to tell it to back off earlier (even easier in v2 - just mv source/raddb/ out of the way), but now for some reason the old v3-style mechanism doesn't work any more.
Well... the build system has changed *completely*.
I guess I could create the mods-config/ dir in my production config dir and it would make the symptom go away.
I still found it worth reporting that some messing-around with the config dir is going on/attempted even when the source dir is told not to do that.
Because the rules for "install to config dir" are scattered through the source, and not all in raddb. So when you nuke raddb, you don't delete all of the rules.
It's not nice if one module makes assumptions about a part of the directory structure it doesn't control. Nothing stops me from deploying a raddb with the configs lying in "raddb/modules-configuration-information/ and it would be very undue if the stock build process bails out on failure then during a subsequent installation.
Well... if you want to create a non-standard configuration, it's up to you to do the work. The default install process assumes that the installation is... a default one. The customization is done via the paths at the top of the Make.inc file. If you want to change *internal* paths, then all bets are off. My only answer is "Good luck!" Alan DeKok.