Bugzilla Bug 51370

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.