[pacman-dev] Makepkg should set environment variables of dependencies before continuing build()
Hi, I would like to submit a problem regarding environment variables when installing make dependencies specified in a PKGBUILD. This is a follow-up of a problem I reported in https://bbs.archlinux.org/viewtopic.php?pid=1211773. This happens when a dependency has an /etc/profile.d shell script which sets one or more environment variables. If this dependency is installed for the first time on a system, these environment variables are not available when the build() fonction is run. This is an issue when these environment variables are required within the PKGBUILD script. As a workaround, maintainers run the profile script of the dependencies directly in in build(). However this may be difficult, especially in case of a meta package with multiple choices. For instance, if makedepends contains a meta package such as "java-environment", and Java has never been installed before, the user will be asked if he wants to install either openjdk6 or jdk7-openjdk. If the build() fonction requires the JAVA_HOME environment variable, which contains the path to java, the maintainer has to source the corresponding /etc/profile.d shell script, but its name is different in jdk6 and jdk7! Thus PKGBUILD maintainers have used various "tricks", such as (see opencascade in AUR): if [ -z $JAVA_HOME ]; then [ -e /etc/profile.d/openjdk6.sh ] && source /etc/profile.d/openjdk6.sh [ -e /etc/profile.d/jdk.sh ] && source /etc/profile.d/jdk.sh fi or (see java-mecab in AUR): if [ -f /etc/profile.d/openjdk6.sh ]; then source /etc/profile.d/openjdk6.sh elif [ -f /etc/profile.d/jdk.sh ]; then source /etc/profile.d/jdk.sh fi As you can see, the goal is the same, but the syntax is different and awkward. There is no official or normalised way to do this. I propose to correct this by making the environment variables immediately available in build() when a package is installed as a dependency. It would be logical that when makepkg installs dependencies, the whole package files but also the environment variables set by this package are available. This would make a PKGBUILD less error-prone by: - undifferenciating if a makedepends is installed for the first time or not - removing the need to source the correct profile shell script, making the task difficult in case of a meta package - making the maintenance of the PKGBUILD easier (what happens when jdk8 is available, and the profile script name has changed again?) Note that "source /etc/profile" in build() is not a good solution, as it runs all profile.d scripts and if one script fails, then the build process is aborted. It is better to fix makepkg upstream. I had a look at the code, and do not understand why run_pacman does not set the variables, but maybe it is a problem of variable space? Eric
On 31/12/12 01:48, Eric Fernandez wrote:
Note that "source /etc/profile" in build() is not a good solution, as it runs all profile.d scripts and if one script fails, then the build process is aborted. It is better to fix makepkg upstream. I had a look at the code, and do not understand why run_pacman does not set the variables, but maybe it is a problem of variable space?
How about: source /etc/profile &>/dev/null on line 483 of makepkg in the handle_deps function right after installing dependencies?
On 31/12/12 01:58, Allan McRae wrote:
On 31/12/12 01:48, Eric Fernandez wrote:
Note that "source /etc/profile" in build() is not a good solution, as it runs all profile.d scripts and if one script fails, then the build process is aborted. It is better to fix makepkg upstream. I had a look at the code, and do not understand why run_pacman does not set the variables, but maybe it is a problem of variable space?
How about:
source /etc/profile &>/dev/null
on line 483 of makepkg in the handle_deps function right after installing dependencies?
Just to be clear, we already do this and it works:
makechrootpkg32 -c -r /home/arch/chroot/testing-i686/ ==> Creating clean working copy...done ==> Making package: foo 1-1 (Mon Dec 31 02:06:03 EST 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... resolving dependencies... looking for inter-conflicts...
Targets (30): ca-certificates-java-20120608-1 freetype2-2.4.11-2 hicolor-icon-theme-0.12-2 inputproto-2.2-1 kbproto-1.0.6-1 libice-1.0.8-1 libjpeg-turbo-1.2.1-1 libpng-1.5.13-1 libsm-1.2.1-1 libx11-1.5.0-1 libxau-1.0.7-1 libxcb-1.9-1 libxdmcp-1.1.1-1 libxext-1.3.1-1 libxi-1.6.1-1 libxmu-1.1.1-1 libxrender-0.9.7-1 libxt-1.1.3-1 libxtst-1.2.1-1 nspr-4.9.4-1 nss-3.14.1-1 recordproto-1.14.2-1 renderproto-0.11.1-2 sqlite-3.7.15.1-1 xcb-proto-1.8-1 xdg-utils-1.1.0.git20121008-1 xextproto-7.2.1-1 xorg-xset-1.2.2-1 xproto-7.0.23-1 openjdk6-6.b24_1.11.5-1 Total Installed Size: 173.10 MiB <snip> ==> Checking buildtime dependencies... ==> Retrieving Sources... ==> Extracting Sources... ==> Entering fakeroot environment... ==> Starting package()... /usr/lib/jvm/java-6-openjdk ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... ==> WARNING: Please add a license line to your PKGBUILD! Example for GPL'ed software: license=('GPL'). -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: foo 1-1 (Mon Dec 31 02:06:19 EST 2012)
Hi Alan, Bizarrely, this was failing in aacskeys. Is this a recent addition? I need to check it again then, but a few months ago, the build was failing on machines where java-environment had not been installed yet. Thanks, Eric
On 31/12/12 02:11, Eric Fernandez wrote:
Hi Alan,
Bizarrely, this was failing in aacskeys. Is this a recent addition? I need to check it again then, but a few months ago, the build was failing on machines where java-environment had not been installed yet.
It has been there for years. Allan
2012/12/31 Allan McRae <allan@archlinux.org>:
It has been there for years.
Allan
Well, I discussed the issue there: https://bbs.archlinux.org/viewtopic.php?id=137555 in March 2012. I am absolutely positive that there was an issue if JAVA_HOME was not previously set (and java-environment had not been installed), and that source /etc/profile.d/jdk.sh was fixing it. Any other idea this was causing it? I'll try to see if I can reproduce it on a virtual environment. Eric
On 31/12/12 21:40, Eric Fernandez wrote:
2012/12/31 Allan McRae <allan@archlinux.org>:
It has been there for years.
Allan
Well, I discussed the issue there: https://bbs.archlinux.org/viewtopic.php?id=137555 in March 2012. I am absolutely positive that there was an issue if JAVA_HOME was not previously set (and java-environment had not been installed), and that source /etc/profile.d/jdk.sh was fixing it. Any other idea this was causing it? I'll try to see if I can reproduce it on a virtual environment.
Eric
Many Arch PKGBUILDs use JAVA_HOME, and all Arch packages are build in a minimal chroot that will require java to be installed. There is only one Arch package that sources anything to get JAVA_HOME and that is because it unsets it first (for some unknown reason...). Allan
2012/12/31 Allan McRae <allan@archlinux.org>:
Many Arch PKGBUILDs use JAVA_HOME, and all Arch packages are build in a minimal chroot that will require java to be installed. There is only one Arch package that sources anything to get JAVA_HOME and that is because it unsets it first (for some unknown reason...).
Allan
I see. For your information, I used java-environment as the makedepends, not a specific java package, since both openjdk6 and jdk7 are available (and let people use the oracle version from AUR). So the problem may have been with one of the java package, and may have been corrected since, instead of a problem with makepkg? That would explain everything. Eric
participants (2)
-
Allan McRae
-
Eric Fernandez