I'm not sure why exactly this happens, and krh did say:

14:29 < krh> maybe we could preserve the launch time environment in the non-root child process (ie weston)

But the build instructions do tell you how to deal with this:  http://wayland.freedesktop.org/building.html

If you are using a distro that does not set $XDG_RUNTIME_DIR for you, do:

    $ mkdir /tmp/wayland
    $ chmod 0700 /tmp/wayland
    $ su -c 'echo XDG_RUNTIME_DIR=/tmp/wayland >> /etc/environment'


(This uses pam.)

Darxus, using /etc/environment is not an option if I want a custom Weston/Wayland environment since it is system-wide, as far as I can tell.

Exporting, for example, GDK_BACKEND=wayland in /etc/environment will break GTK+ when I run them in Ubunutu+X+Compiz.

If weston-launch didn't clear environment variables, I could launch weston with a simple script that looks like this:

source wayland-vars.sh
weston-launch

And everything in Weston would "just work". For example GTK+ programs launched from the panel would use the Wayland GDK backend.

<pq> Darxus, XDG_RUNTIME_DIR is defined to be per-user, and private. If you set it in /etc/environment, it will be a permanent, system wide setting for all users.
<pq> using chmod as in the guide will probably avoid some security leaks, but it also breaks it for every other user on the system
<pq> ... http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html defines XDG_RUNTIME_DIR, and what properties it must have.

Added a statement about these concerns to the build instructions ( http://wayland.freedesktop.org/building.html ), and linked to this bug.

Seems like, with the mentioned concerns, this should be a blocker?

Quoting the spec:

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Sorry.  Mind my confusion; I didn't read properly.

The spec doesn't say much on this issue at all -- it's GLib that uses ~/.cache/ as the default...

Probably I should update the spec to be more specific.

I have opened bug 62092 for the XDG_RUNTIME_DIR case, which is a different bug than the originally reported here (weston-launch clearing the environment).

This bug is blocking all weston-unit tests that run on the DRM engine (after a small patch is applied bug #62871 ).

Hi,

The environment is dropped in weston-launch main from a call to clearenv().
Disabling this preserves my environment variables.

Is there something I'm overlooking here?

Commit that implemented this explains the reason:

commit 272d243e00c742f9cffc8bc46d09b7d0f19dc43e
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Tue Jan 29 14:14:06 2013 -0500

    weston-launch: Clear environment and set it up from scratch
    
    With recent systemd[1] XDG_VTNR will leak through to pam, which ends up
    setting a vtnr pam argument with the wrong value.  The fix is to clear
    XDG_VTNR first, but what we should have been doing all along is resetting
    the environment.
    
    Thanks to Ray Strode for helping debug this.
    
    [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=a8573ccc35a4efe8900be5d48c6c803670540c2b

Somebody want to verify this was fixed by this commit?  

http://cgit.freedesktop.org/wayland/weston/commit/?id=ff3230952a68077669e0ea0ac3ceb234273556fc

Hi thanks for your bug report:

The clearing of the environment variables is intentional for security purposes. 

With the change: http://cgit.freedesktop.org/wayland/weston/commit/?id=ff3230952a68077669e0ea0ac3ceb234273556fc

You can have things like GDK_BACKEND=wayland setup in your login shell.

@Rob Bradford: Setting these variables in the login shell would not help for applications launched directly from weston... At the moment, the only thing that can be launched directly from weston is a terminal, but it wouldn't be unthinkable to be able to launch other applications from inside weston, in which case setting the variables in the login shell wouldn't be particularly useful...

(In reply to comment #13)
> @Rob Bradford: Setting these variables in the login shell would not help for
> applications launched directly from weston... At the moment, the only thing
> that can be launched directly from weston is a terminal, but it wouldn't be
> unthinkable to be able to launch other applications from inside weston, in
> which case setting the variables in the login shell wouldn't be particularly
> useful...

After the comment Rob pointed out, weston-launch will run a login shell that will in turn launch weston. That way any change in the environment made by the login shell should be inherited by weston and any process it launches.