I'm uncertain why AMANDA_SERVER, AMANDA_SERVER_TAPE, and AMANDA_SERVER_INDEX aren't honored in the ebuild. There's a large configuration section that should catch these, however when the compile occurs its using defaults. I'm doing: AMANDA_SERVER=localhost emerge amanda which ought to be sufficient. I've ended up directly modifying the options passed to configure in the ebuild. Russell Reproducible: Always Steps to Reproduce: 1. 2. 3.
which version of amanda? please supply the output of emerge --info as requested i've had several times that passing env vars this way, the env vars won't be recognized by the ebuild. what happens when you do: export AMANDA_SERVER=localhost emerge amanda
emerge --info: keroberos root # emerge --info Portage 2.0.50-r6 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.26) ================================================================= System uname: 2.4.26 i686 Intel(R) Celeron(R) CPU 1.70GHz Gentoo Base System version 1.4.10 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/ http://128.213.5.34/gentoo/ http://ftp-mirror.internap.com/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb cdr crypt encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib jpeg kde libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcpd truetype x86 xml2 xmms xv zlib" Yes, I tried the export route. I also tried to modify the ebuild to change the defaults in the configuration section. The amanda_variable_setup() routine is called in all the ebuild functions EXCEPT the compile function (which is where its really needed...). Simply adding it in didn't help though. However, I'm concerned that the environment variables aren't reaching the ebuild... I added debugging lines to print the variables passed to amanda_variable_setup() and its always using the defaults, as if the environment vars didn't exist. Next up I tried using USE=debug to trigger some of the informational einfo calls in the ebuild, that didn't work either. Is there something hosing the environment here?
Ack, sorry. I'm using amanda-2.4.4-r3.ebuild.
ok, seems like this error is triggered when amanda has already been installed and has placed it's settings in /etc/env.d/97amanda. these settings are placed in /etc/profile.env by env-update. the ebuild command sources these settings and will override settings you specifiy via command line. you can delete /etc/env.d/97amanda and run "env-update && source /etc/profile" afterwards to get rid of these settings. or edit the settings in /etc/env.d/97amanda to fit your needs and then run the above command.
You're most likely 100% correct. I had installed it first with defaults, having forgotten to specify "localhost" for my AMANDA_SERVER. I think that ought to be default anyway. ;] At least, that was the default in the amanda ebuild I created ages ago. Nevermind, and thanks for the assistance. I was worried there for a bit. =] Russell
the behavior of the ebuild is definetly correct, however it _is_ affected by how portage caches the environment. if you do: 'USE=debug AMANDA_SERVER=test1 emerge amanda' then cancel it after it's about to unpack, it will have those environment variables cached. then if you do 'emerge amanda' again, it will use those environment variables. if you do happen into this, just remove the amanda build dir, /var/tmp/portage/amanda* and run emerge again with your new env vars and they will override the ones in /etc/env.d/97amanda. I went to a lot of effort to make sure the environment stuff worked correctly. the behavior of amanda_variable_setup is as such: 1. make a backup of current env 2. read in the defaults from the ebuild 3. read in your existing env file if any 4. apply the backup of the current env this process takes some time, so in src_unpack, once it's safe to write files, i make a cache file of my own, and write the final data out to it, and then i source that file in the rest of the ebuild instead of using amanda_variable_setup. The entire reason I invented the crazy enviroment variable system for amanda was so that I could install a full server farm with the minimum of effort, while still being customizable.
> the behavior of amanda_variable_setup is as such: > 1. make a backup of current env > 2. read in the defaults from the ebuild > 3. read in your existing env file if any > 4. apply the backup of the current env Robin, what I wanted to say in comment 4 is that I see one problem for this. As I said, the ebuild command (run directly or via emerge) will set up the environment for building. And this includes sourcing /etc/profile which sources /etc/profile.env and this includes the contents of /etc/env.d/97amanda. So when I specify AMANDA_SERVER in my environment before I call emerge/ebuild the variable will get overwritten when emerge/ebuild sets up the build environment. When you do a backup of the current environment in your ebuild, you'll backup the settings from /etc/env.d/97amanda. The user has no possibility of specifiying new values via command line. He has to edit /etc/env.d/97amanda. I modified the ebuild to print out the variable AMANDA_SERVER when it is sourced, I put it not in any function. AMANDA_SERVER is set to localhost in /etc/env.d/97amanda. Here's the result: mrx-nb root # ebuild /usr/portage/app-admin/amanda/amanda-2.4.4-r3.ebuild unpack >>> md5 src_uri ;-) amanda-2.4.4.tar.gz AMANDA_SERVER=localhost berkdb AMANDA_SERVER=localhost >>> Unpacking source... >>> Unpacking amanda-2.4.4.tar.gz to /var/tmp/portage/amanda-2.4.4-r3/work >>> Source unpacked. mrx-nb root # rm -r /var/tmp/portage/amanda-2.4.4-r3/ mrx-nb root # export AMANDA_SERVER=mrx-nb mrx-nb root # ebuild /usr/portage/app-admin/amanda/amanda-2.4.4-r3.ebuild unpack >>> md5 src_uri ;-) amanda-2.4.4.tar.gz AMANDA_SERVER=localhost berkdb AMANDA_SERVER=localhost >>> Unpacking source... >>> Unpacking amanda-2.4.4.tar.gz to /var/tmp/portage/amanda-2.4.4-r3/work >>> Source unpacked. maybe portage should provide the ebuilds with some function to store values between emerges, so that the ebuild don't use /etc/env.d which is really bad because these ones are global and we'll end up with a lot of variables in the user's environment. I'm thinking of something like I proposed in bug 51061 but modifyable by ebuilds. Comments?
i've filed bug #51552, in your further testing there (i've reproduced it now too), i see that the behavior of portage has changed since I wrote the amanda ebuilds originally. thanks.
fixed in portage now.
apparently not
*** Bug 130229 has been marked as a duplicate of this bug. ***
*** Bug 123563 has been marked as a duplicate of this bug. ***
*** Bug 131920 has been marked as a duplicate of this bug. ***
*** Bug 51552 has been marked as a duplicate of this bug. ***
*** Bug 128420 has been marked as a duplicate of this bug. ***
*** Bug 142076 has been marked as a duplicate of this bug. ***
Why don't we just stack profile.env inside portage.config, since we already to environment stacking there anyway? Here's the current stacking order: globals defaults conf pkg auto backupenv env How about if we slide it in between auto and backupenv?
This is fixed in svn r4048.
This has been released in 2.1.1_pre4-r1.
