Update gnome-initial-setup vendor configuration path #136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was introduced in 6740898 but gnome-initial-setup upstream instead grew support for reading a list of pages to skip from a keyfile, so in c4af6b0 (also known as endlessm/endless-image-config@f241f00) this was removed everywhere except this hook. https://phabricator.endlessm.com/T35040
The only use of this variable was removed in September 2019. endlessm/endless-image-config@30510a9 https://phabricator.endlessm.com/T35040
Previously we built GNOME Initial Setup to use the path /var/lib/eos-image-defaults/branding/gnome-initial-setup.conf and installed the keyfile specified in the '[image] branding_fbe_config' key there. (There was no validation that its name was actually gnome-initial-setup.conf, which was necessary for it to work.) When we contributed this feature upstream to gnome-initial-setup, the path was made configurable with a build-time parameter, with no default. Some time later, Initial Setup started reading /etc/gnome-initial-setup/vendor.conf if present; and /usr/share/gnome-initial-setup/vendor.conf otherwise. It retained a build-time parameter, which we continued to set; but setting that parameter disabled *both* of the upstream paths. With the upstream behaviour, it is possible to ship overrides in the immutable bit of the OS, and further override them in /etc. This is in my opinion preferable to what we have historically done, to always write a file in /var for all images, even if the specific image does not want any image-specific customisation of Initial Setup. Install any config file to the upstream path in /etc, matching a build configuration change I will make in our gnome-initial-setup package. https://phabricator.endlessm.com/T35040
This will instead be installed by eos-theme, to a location in /usr. https://phabricator.endlessm.com/T35040
dbnicholson
approved these changes
Dec 5, 2023
41 tasks
|
I'm going to go ahead and merge this because the vanilla Debian copy of gnome-initial-setup we have in eos:master:core already uses the upstream paths. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously we built GNOME Initial Setup to use the path
/var/lib/eos-image-defaults/branding/gnome-initial-setup.confandinstalled the keyfile specified in the
[image] branding_fbe_configkeythere. (There was no validation that its name was actually
gnome-initial-setup.conf, which was necessary for it to work.)When we contributed this feature upstream to gnome-initial-setup, the
path was made configurable with a build-time parameter, with no default.
Some time later, Initial Setup started reading
/etc/gnome-initial-setup/vendor.confif present; and/usr/share/gnome-initial-setup/vendor.confotherwise. It retained abuild-time parameter, which we continued to set; but setting that
parameter disabled both of the upstream paths.
With the upstream behaviour, it is possible to ship overrides in the
immutable bit of the OS, and further override them in
/etc. This is inmy opinion preferable to what we have historically done, to
always write a file in
/varfor all images, even if the specific imagedoes not want any image-specific customisation of Initial Setup.
/etc, matching a buildconfiguration change I will make in our gnome-initial-setup package.
gnome-initial-setupvendor.confin favour of Install & migrate gnome-initial-setup vendor.conf file eos-theme#392.https://phabricator.endlessm.com/T35040