Code like this, as seen in the amanda ebuilds, doesn't work for binpkgs. MYTMPDIR="${WORKDIR}/tmp" ENVDIR="/etc/env.d" ENVDFILE="97amanda" TMPENVFILE="${MYTMPDIR}/${ENVDFILE}" [...] src_unpack() { [...] # Now we store the settings we just created set | egrep "^AMANDA_" > "${TMPENVFILE}" } pkg_postinst() { [ ! -f "${TMPENVFILE}" ] && die "Variable setting file (${TMPENVFILE}) should exist!" source ${TMPENVFILE} [...] }
come up with a solution that doesn't require putting the env capture in the binpkg, and then we'll talk.
Allowing the user to change behaviour via environment variables is (currently) bad. With new portage versions the environment will be re-used and you'll have access to the stored environment without any special magic. As a workaround you could dump the envfile to /usr/share/amanda instead of WORKDIR, and source it from the merged package.
Yes, with new portage versions it's less of a problem, but I've had the amanda packages the way they are as I needed that functionality with old versions of portage, and the only way around that would be to put a DEPEND on the portage version just for the sake of the env vars. It's significent functionality of Amanda that can only be controlled at build time - AMANDA_PORTS* most importantly, to work with firewalls; AMANDA_DBMODE secondly. If I change TMPENVFILE to be in /usr/share/amanda for the pkg_postinst phase, and copy it into ${D}/usr/share/amanda during src_install, I could then rm it at the end of pkg_postinst. - Would this be an acceptable solution.
Created attachment 74103 [details, diff] copies ENVDFILE to /usr/share/amanada The patch implements the suggested fix: it copies 97amanda to /usr/share/amanda during install and removes it in pkg_postinst.
applied for 2.4.5_p1. Not applying to older versions, I intend to remove them soon.
