FAQ: 'back to normal Fedora defaults' method is outdated, as of 3.5.0

[jamesericdavidson]

The FAQ describes restoring Fedora defaults like so:

sudo rm -f /etc/dconf/db/local.d/01-ublue

As of 3.5.0, the file has moved to /usr/share/glib-2.0/schemas/zz0-bluefin-modifications.gschema.override, as per the diff.

Unlike the previous method, the file cannot be outright removed at runtime as /usr/share is read-only.

[castrojo]

Nice catch! @fiftydinar do you have any recommendations on how we can support people who want a vanilla GNOME experience?

[fiftydinar]

Oh, forgot that you have this in documentation.

I think that we can have ujust script, which dumps all gschema XMLs + overrides + dconfs that are not Bluefin's, & dconf load's them.
For convenience, we can place those in /usr/share/ublue-os/dconfs/vanilla/, so we load them.

We can easily convert gschema-overrides on the fly with the script I made for Bazzite's PR (dconf-override-converter). For gschema XML's, I'll have to see.

[fiftydinar]

On another note, I think that we can just utilize /usr/local/share/glib-2.0/schemas/ or ${HOME}/.local/share/glib-2.0/schemas/ location for dumping all Gschema XMLs & overrides that are not Bluefins. Than do glib-compile-schemas. Those will then override the default location.

For reverting to default, just remove all those files there & voila, you're back.

Will test all of this

[fiftydinar]

Custom-image maintainers can solve this issue by removing zz0-* gschema overrides in /usr/share/glib-2.0/schemas/ & compiling gschema with glib-compile-schemas. Along with removing dconfs in /etc/dconf/db/distro.d/

Regarding local-users, I can definitely conclude that pure dconf approach is simpler in this regard.

But, I think that with this approach, we can mitigate this:

In build-time:

• Copy gschema-override to /usr/share/ublue-os/dconfs/
• Convert it to dconf with dconf-override-converter
  (manually fix key name of "sort-folders-first" with sed, as it's slightly different)
• Mirror the default values from Fedora in that dconf (either manually or automatically, maybe some XML parsing can help us with that, but it can be too complex)
• Rename the converted dconf to vanilla-fedora-settings

On boot:

• In user-setup, on every boot, copy vanilla-fedora-settings from /usr/share/ublue-os/dconfs/ to /etc/dconf/db/local.d/, if vanilla-fedora-settings dconf is available in local.d folder. This will assure that dconf is updated over-time when just script is used (see below).

Have a just script which would do this:

Going to Vanilla settings:

• Remove dconfs in /etc/dconf/db/distro.d/
• Copy vanilla-fedora-settings dconf from /usr/share/ublue-os/dconfs/ to /etc/dconf/db/local.d/
• Do dconf update

Going back to Bluefin settings:

• Copy dconfs from /usr/etc/dconf/db/distro.d/ to /etc/dconf/db/distro.d/
• Remove vanilla-fedora-settings dconf from /etc/dconf/db/local.d/
• Do dconf update

What are your thoughts?

[castrojo]

Would a vanilla session in GDM be easier?

[fiftydinar]

Would a vanilla session in GDM be easier?

I don't know how to achieve that, but sounds like another idea to explore

[m2Giles]

Think we can declare sessions in /usr/local/share/wayland-sessions

[fiftydinar]

Researching about how sessions work, I think that it would be easier & more future-proof to solve this issue like I described in this comment: #1743 (comment)

If someone has a different opinion regarding this, please tell.

[dosubot]

Hi, @jamesericdavidson. I'm Dosu, and I'm helping the bluefin team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• The FAQ for restoring Fedora defaults is outdated due to changes in version 3.5.0.
• The relevant file has moved to a read-only directory.
• Discussions include using scripts for schema overrides and dconf settings.
• Suggestions involve using local directories and scripts to toggle settings.
• Potential session declarations in /usr/local/share/wayland-sessions were mentioned.

Next Steps:

• Is this issue still relevant to the latest version of the bluefin repository? If so, please comment to keep the discussion open.
• Otherwise, this issue will be automatically closed in 14 days.

Thank you for your understanding and contribution!