Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Hey Tim,

>> Turns out that the problem was with a stale /var/lib/gdm – which makes
>> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
>> account’s home directory.  But it’s not like this really needs to be
>> persistent, I think.
>>
>> I moved it out of the way and the gdm login prompt appeared within a few
>> seconds.  After restarting xorg-server the directory was recreated.
>>
>> Now, I *still* cannot actually log in, but the problem is likely very
>> similar.
>>
>> [two minutes pass]
>>
>> Yup, after moving /home/rekado/.cache out of the way, everything is fine
>> and I can log in.
>>
>> What should we do about this?  For gdm I think it would make sense to
>> add an activation service extension that clears the gdm user’s home
>> directory.  And more generally, maybe we should offer a generic cache
>> cleaner service.
>>
>> Thoughts?
>
> I had a similar issue where the UID of the “gdm” user had changed
> between reconfigures.  I think it happened because I removed the GDM
> service for a while and then brought it back.  It took me a while to
> figure it out, because of course everything looks fine at first glance.
> However, GDM could no longer access “/var/lib/gdm”, and I had to remove
> it to fix the problem.
>
> The X.org logs all end up in that directory, so it might a little
> frustrating for someone having X.org issues if we delete that directory
> all the time.  I don’t remember if they get copied anywhere else.

Can we cause the logs to be put in /var/log with all the other logs?

> Maybe it would make more sense to delete the “/var/lib/gdm/.cache”
> folder and ensure the permissions of the rest of it in an activation
> script.  WDYT?

That would work, too, though the .local directory (this time in my own
user’s home directory) has proven to be harmful in my past work on GNOME
upgrades.

--
Ricardo