Merge lp:~3v1n0/nux/x11-conffile-on-unity-only into lp:nux/bionic
Status: | Rejected |
---|---|
Rejected by: | Marco Trevisan (Treviño) |
Proposed branch: | lp:~3v1n0/nux/x11-conffile-on-unity-only |
Merge into: | lp:nux/bionic |
Diff against target: |
56 lines (+25/-4) 3 files modified
debian/50_check_unity_support (+14/-2) debian/changelog (+9/-0) m4/gtest.m4 (+2/-2) |
To merge this branch: | bzr merge lp:~3v1n0/nux/x11-conffile-on-unity-only |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Iain Lane | Approve | ||
Review via email: mp+347863@code.launchpad.net |
Commit message
X11-check-
The content of $XDG_CURRENT_
not to affect the value of IFS for all the scripts sourced by the X session.
If running in Unity we should call unity_support_test, not inside gnome
ubuntu X sessions.
XDG_CURRENT_DESKTOP values are currently the followings:
- unity before 17.10: Unity
- unity after 17.10: Unity:Unity7:ubuntu
- gnome session: GNOME
- ubuntu gnome session: ubuntu:GNOME
Also, at debian level, don't consider the Xsession.d script as a config file anymore
This is just a script to be loaded, and not something the user is supposed to change,
so it should be removed on simple package removal.
To achieve this, as per maintainer-guide 5.3, using sym-links is the standard way.
Description of the change
Backport to Bionic
Unmerged revisions
- 895. By Marco Trevisan (Treviño)
-
Revert: "debian: don't consider the Xsession.d script as a config file anymore"
It seems something there's not full agreement on it, so to avoid further discussions
I'm reverting this back. However I strongly believe that given the current tools we have
this is the way to go, as debian doesn't provide other tools to get this done.
Nor X11 can move files outside of /etc. - 894. By Marco Trevisan (Treviño)
-
gtest: update default google-test prefix to match distro
Thanks for the changes.
No sorry, I can't ack the symlink change. I don't think this complies with the Debian recommendations. It talks about whether *every* user has to modify the file, which isn't the case here. I don't see why this file is different to any of the other ones. Can we please just not rename it?
The rest of it looks good. I tested the subshell bit using /bin/sh here and it seems to work fine, thanks for doing it like that.