unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Timothy Sample <samplet@ngyro.com>
To: guix-devel@gnu.org
Subject: GDM future work
Date: Sun, 30 Dec 2018 11:56:24 -0500	[thread overview]
Message-ID: <87y387kl6v.fsf@ngyro.com> (raw)

Hi Guix,

I have been using GDM on GuixSD for the past few days, and I am quite
happy with it.  A few patches that make it usable just landed on
master.

Now, there is a lot of room left for cleaning it up, but I need some
advice.

The main issue is the way that GDM launches the session bus (the
instance of D-Bus that manages the session).  It launches it from a
clean environment that has little more than what PAM gives from
“/etc/environment” (and “~/.pam_environment”, if it exists).  The result
is that D-Bus can’t find any services, because it doesn’t have
“XDG_DATA_DIRS” set.

Currently, this is solved by patching GDM to thread “XDG_DATA_DIRS” into
the process the launches D-Bus, but that’s not great.  There are at
least two better options.

(1) Extend the PAM environment service so that it puts important
environment variables for D-Bus in “/etc/environment”.  This is easy to
do, and fits pretty naturally with the way that GDM works.

(2) Set up a wrapper script for D-Bus like the wrapper script we
currently use for X.  This way, we could very precisely set up where the
session bus looks for system and user service files.  This seems to be
more like “the Guix way”, but it would mean threading a
“GDM_DBUS_LAUNCH” environment variable through the GDM code (like we
currently do with “GDM_X_SERVER”).

Besides these two options, I get tempted to think even bigger.  We could
replace a lot of the GDM session initialization code with our own code,
and then if we only had per-session Shepherd instances….  That’s
probably too big for right now.  :)

I lean towards option 2, because my understanding is that, in general,
Guix prefers static configuration over dynamic configuration.  This
means that the discoverability gained by option 1 is actually a
liability, since it creates a way for dependencies to exist which are
not declared statically.  The other advantage that option 2 has is that
it would be possible to find service files from the user’s profile.  By
doing this, we avoid having to tell everyone about “~/.pam_environment”
and what to put in there to make D-Bus aware of services in the user’s
profile.

Thoughts?

Besides this, there are few straight-forward things to do.  We need to
make a “libgdm” package that does not depend on “gnome-shell” [1].  It
would be nice to fill out the config record and get rid of the opaque
configuration text file.  We need documentation for GDM in the manual.
Finally, I already miss the Guix logo from SLiM, so even if it is not
the default, I would like a Guix theme to be available.  :)

I will chip away at these as I have time, but of course anyone is
welcome to jump on them if I’m too slow.


[1] https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00231.html


-- Tim

             reply	other threads:[~2018-12-30 16:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-30 16:56 Timothy Sample [this message]
2019-01-05 21:21 ` GDM future work Ludovic Courtès
2019-01-06 15:10   ` Timothy Sample
2019-01-09 15:17     ` Ricardo Wurmus
2019-01-09 21:40     ` Ludovic Courtès
2019-01-09 22:32       ` Timothy Sample
2019-01-10  0:15         ` Catonano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y387kl6v.fsf@ngyro.com \
    --to=samplet@ngyro.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).