Cannot source /etc/profile from within the PKGBUILD anymore

zebulon · 2012-12-28 14:54:34

Hi,

Short story: the command

source /etc/profile

within the build() section of my PKGBUILD now returns a build() error. It used to work before, is there a reason for this? Should it be executed in another section than build()? (Note source /etc/profile works properly in console, within the build directory)

Long story:
I need to use $JAVA_HOME in my PKGBUILD (to patch a lua source file with the current JDK path, which can be detected with $JAVA_HOME. Patching is done with a sed command). However, if java-environment is installed for the first time (as a makedepends) along with my package, then I need to source /etc/profile first to set the $JAVA_HOME environment variable, before being able to use it within my build() section. Otherwise it is not set yet and building fails.

Many thanks for your help.

Last edited by zebulon (2012-12-28 14:57:23)

tdy · 2012-12-29 21:13:38

If you source the /etc/profile.d/locale.sh file and your /etc/locale.conf only contains LANG (which I suspect is the case for a lot of people), then the LC_* lines at the bottom will leave an exit code of 1 and cause makepkg to abort.

Several workarounds here, but only the first option will work atm without intervention from the end-user or patching the filesystem package.

a) Replace `source /etc/profile' with something like this to skip the locale profile

  for _profile in /etc/profile.d/*.sh; do
    [[ $_profile != /etc/profile.d/locale.sh && -r $_profile ]] && . "$_profile"
  done
  unset _profile

b) Add "|| /bin/true" to the last line of /etc/profile.d/locale.sh

[ -n "$LC_IDENTIFICATION" ] && export LC_IDENTIFICATION || /bin/true

c) Add the complete output of `locale' to your /etc/locale.conf or ~/.config/locale.conf

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

Last edited by tdy (2012-12-29 22:18:58)

tdy · 2012-12-29 21:35:31

As a side note, since you're patching the lua package, wouldn't it be better to make it pull the jdk path via os.getenv("JAVA_HOME") at runtime? By hardcoding the jdk path into the lua source, java-environment becomes a hardcoded dependency instead of a makedepends. The end-user is tied to the specific implementation of java that was used during the building of the lua package.

Last edited by tdy (2012-12-29 21:47:21)

zebulon · 2012-12-30 06:05:12

Hi,

Many thanks for the advice. I was unclear though: I maintain the aacskeys package in AUR, not the lua package. However, the file I am patching in aacskeys is named premake.lua, used for the project file generator premake.sourceforge.net.

I'll try your first suggestion, since this is the only one which may work without touching the system. Another alternative would be to directly source the /etc/profile.d/jdk.sh file. EDIT: nope, because there could be openjdk6.sh instead. I really need to be able to source the correct file. The maintainer of opencascade uses:

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

which is efficacious but less generic.

Besides, is it normal that we get this error code, since the Arch documentation only recommends to set LANG in /etc/locale.conf? SHould I report it as a bug or request a design change for /etc/profile.d/locale.sh there (as suggested in your (b) entry)? I am asking this because my PKGBUILD is not the only one to use this trick, and this problem breaks them all.

Thanks.

Last edited by zebulon (2012-12-30 06:14:58)

zebulon · 2012-12-30 06:35:12

java-mecab uses another syntax for sourcing the java envars:

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

I realise that this may be a better solution than a full source /etc/profile, since source /etc/profile is sensitive to an error in any /etc/profile.d/* script.
It would be nice to have an official, fail-safe way to source the profile scripts though, since many PKGBUILD use their own recipes (see java-mecab, which tests the presence of the jdk files vs opencascade, which tests if JAVA_HOME is set). What is the best practice?

zebulon · 2012-12-30 06:40:08

I am now wondering if the best fix would be very upstream: that when a dependency is installed during the PKGBUILD build() script, it runs the profile.d scripts of the package before continuing to build the package. This way, we would not need to worry about which environment variable/which script to run within the build section. What do you think?

tdy · 2012-12-30 08:01:30

zebulon wrote:

I am now wondering if the best fix would be very upstream: that when a dependency is installed during the PKGBUILD build() script, it runs the profile.d scripts of the package before continuing to build the package. This way, we would not need to worry about which environment variable/which script to run within the build section. What do you think?

If there's something to be patched upstream, this is probably the way to go. The "|| true" hack seems ugly, and I doubt they'd want to add that to the locale conf.

I suggest pitching the idea to the pacman-dev mailing list to see what they think about it and whether anyone has interest/time in implementing it.

zebulon · 2012-12-30 09:50:42

Thanks, will do. I guess this should be a fix in makepkg?

Last edited by zebulon (2012-12-30 09:55:48)

zebulon · 2012-12-30 15:08:33

tdy wrote:

If there's something to be patched upstream, this is probably the way to go. The "|| true" hack seems ugly, and I doubt they'd want to add that to the locale conf.

You are right, but at the same time I think the locale.sh script should succeed anyway. This is a separate issue and may be handled using a bug report.

Allan · 2012-12-30 16:10:21

zebulon wrote:

However, if java-environment is installed for the first time (as a makedepends) along with my package, then I need to source /etc/profile first to set the $JAVA_HOME environment variable, before being able to use it within my build() section. Otherwise it is not set yet and building fails.

Wrong... makepkg sources /etc/profile after installing deps.

tdy · 2012-12-30 22:54:30

Hah, so I guess this was all moot. Anyway, good to know.

zebulon · 2012-12-31 04:13:56

Hi,

Well I guess this is new: the problem occurred a few months ago with aacskeys, and was discussed on this forum. That is why many PKGBUILD still have code to detect JAVA_HOME in their build() section.
Are you positive this is not a concern anymore whatever the selected jdk, and that this should be removed from PKGBUILDs? I am going to test builds in fakeroots to confirm.

Thanks.

tdy · 2012-12-31 04:26:19

zebulon wrote:

That is why many PKGBUILD still have code to detect JAVA_HOME in their build() section.

Unfortunately that doesn't mean too much. We still see a lot of deprecated remnants like "$startdir/src" and "|| return 1" in many PKGBUILDs.

edit: Just tried a dummy package in a clean makechrootpkg jail, and $JAVA_HOME is being echoed successfully within build() for me.

Last edited by tdy (2012-12-31 04:45:24)

zebulon · 2012-12-31 09:00:31

tdy wrote:

zebulon wrote:
That is why many PKGBUILD still have code to detect JAVA_HOME in their build() section.
Unfortunately that doesn't mean too much. We still see a lot of deprecated remnants like "$startdir/src" and "|| return 1" in many PKGBUILDs.
edit: Just tried a dummy package in a clean makechrootpkg jail, and $JAVA_HOME is being echoed successfully within build() for me.

That is good to know. I can assume that the i686 or x86_64 architectures would behave the same way. I am absolutely certain this was not working without it a few months ago on a x86_64 machine, but maybe this has changed since then.

I will edit the wiki to specify that sourcing is not necessary anymore, this is useful for maintainers.

Arch Linux

#1 2012-12-28 14:54:34

Cannot source /etc/profile from within the PKGBUILD anymore

#2 2012-12-29 21:13:38

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#3 2012-12-29 21:35:31

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#4 2012-12-30 06:05:12

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#5 2012-12-30 06:35:12

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#6 2012-12-30 06:40:08

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#7 2012-12-30 08:01:30

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#8 2012-12-30 09:50:42

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#9 2012-12-30 15:08:33

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#10 2012-12-30 16:10:21

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#11 2012-12-30 22:54:30

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#12 2012-12-31 04:13:56

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#13 2012-12-31 04:26:19

Re: Cannot source /etc/profile from within the PKGBUILD anymore

#14 2012-12-31 09:00:31

Re: Cannot source /etc/profile from within the PKGBUILD anymore

Board footer