You are not logged in.
After pulling my hair out for about an hour about why building aur/texmacs-pure package ended up having files in my $HOME dir in it, I would like to recommend the following:
makepkg should definitely (by default or as an option) have the capability to sanitize the $PATH before building packages.
What happened to me is actually quite benign, but it could be worse: people may have private builds of compilers, build tools, system utilities, etc. on their $PATH, and these would be used without warning by any upstream build system which isn't careful about this.
I would suggest setting
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
, as is done at the top of /etc/profile, or perhaps source /etc/profile entirely, in order to pick up additions to $PATH done by any dependency packages. Also, any PKGBUILDS that absolutely need to have extra things on the $PATH, can easily set it inside the build() or package() functions.
Any comments or suggestions are welcome.
Last edited by ackalker (2013-03-05 00:25:44)
Offline
Probably better if you made this a bug report rather than a forum post.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
You're probably right, but I didn't want to risk a simple, harsh 'wontfix' reply from the devs to cause this (IMHO) important issue to be swept under the rug ;-)
Last edited by ackalker (2013-03-05 00:28:43)
Offline
I think you'd better explain your issue a bit more, before asking for global changes to makepkg. I just built that package with no problems - it contains the following files:
$ pacman -Qlp ../texmacs-pure-0.57-2-x86_64.pkg.tar.xz
texmacs-pure /usr/
texmacs-pure /usr/share/
texmacs-pure /usr/share/TeXmacs/
texmacs-pure /usr/share/TeXmacs/packages/
texmacs-pure /usr/share/TeXmacs/packages/puredoc.ts
texmacs-pure /usr/share/TeXmacs/plugins/
texmacs-pure /usr/share/TeXmacs/plugins/pure/
texmacs-pure /usr/share/TeXmacs/plugins/pure/doc/
texmacs-pure /usr/share/TeXmacs/plugins/pure/doc/pure-abstract.en.tm
texmacs-pure /usr/share/TeXmacs/plugins/pure/doc/pure-descr.en.tm
texmacs-pure /usr/share/TeXmacs/plugins/pure/doc/pure-texmacs.en.tm
texmacs-pure /usr/share/TeXmacs/plugins/pure/doc/pure.en.tm
texmacs-pure /usr/share/TeXmacs/plugins/pure/progs/
texmacs-pure /usr/share/TeXmacs/plugins/pure/progs/init-pure.scm
texmacs-pure /usr/share/TeXmacs/plugins/pure/progs/pure-input.scm
texmacs-pure /usr/share/TeXmacs/plugins/pure/progs/texmacs.pure
I have encountered the files-from-$HOME-in-package issue once or twice,but it was always traced back to a faulty PKGBUILD, Has this happened with any other packages you built?
Offline
If you want packages built in a clean environment, build them in a clean environment... Look into devtools.
Offline
@tomk: Perhaps you missed the link to the AUR in my first post. In a comment I explained exactly what happened, but I'll summarize it here:
I am using a wrapper script (which is in ${HOME}/bin, which is on my $PATH) for starting TeXmacs. This wrapper gets picked up by upstream's Makefile, which in turn decides that $HOME must be where I've installed TeXmacs.
I think that requiring people to setup a proper buildroot just to build a few packages every now and then is a bit too much to ask, an option to clean out the environment variables with which they are built is more than enough to remedy 99% of the potential problems.
Last edited by ackalker (2013-03-05 15:19:18)
Offline
I think it's a pretty wise rule not to muck around with other people's environments in your program. What if you, for whatever reason, actually want makepkg to use a modified PATH? It's not up to the devs to decide whether or not that situation might ever arise, because the moment it does, they'll have to deal with a complaint about makepkg changing the user's PATH without their explicit intent to do so.
Offline
Packages are meant to be installed system-wide, so you can reverse the question: is it okay for a package's build system to muck about with the system-wide environment (by incorporating random user settings into it) when the package is installed?
Last edited by ackalker (2013-03-05 15:25:06)
Offline
Insecure RPATHs are one prime example where the general verdict seems to be a resounding 'No'.
Offline
Packages are meant to be installed system-wide, so you can reverse the question: is it okay for a package's build system to muck about with the system-wide environment (by incorporating random user settings into it) when the package is installed?
But then that's a problem that needs to be fixed in the package upstream, not in makepkg.
Offline
Other potential culprits (gathered from a one-minute Google search):
$JAVA_HOME
$PYTHONPATH
$GOPATH
$GHC_PACKAGE_PATH
Offline
Packages are meant to be installed system-wide,
Also, that statement is false. Unless a package has a shitty build system, it should be able to accept the "prefix" and "DESTDIR" variables, which allow the user to install wherever he wants, which may not necessarily be system-wide.
Offline
I am using a wrapper script (which is in ${HOME}/bin, which is on my $PATH) for starting TeXmacs. This wrapper gets picked up by upstream's Makefile, which in turn decides that $HOME must be where I've installed TeXmacs.
OK... if I understand you correctly, you're suggesting that makepkg should be altered to workaround a known upstream bug?
Offline
makepkg will not change in this regard - as I said above, build your packages in a clean chroot using devtools.
Offline
If you're responding to me, Allan, well yeah, I already know that.
I guess I want the OP to give his original request a bit more thought.
Offline
#!/bin/bash
PATH=... \
JAVA_HOME=... \
PYTHONPATH=... \
GOPATH=... \
GHC_PACKAGE_PATH=... \
/usr/bin/makepkg "$@"
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
If you're responding to me, Allan, well yeah, I already know that.
More of a reinforcement of your message than a reply.
Offline
I'm sitting on a solution which I want to test some more.
Basically, the script
- clears out the environment by recursively calling itself using env -i
- sources the files under /etc/profile.d
- adds any variables with values specified by the user
- finally, executes the command specified by the user
I might post it when I'm satisfied with it.
Offline