Fedora 34 Extensions Installed from DNF Disabled after Upgrade to Fedora 35


I use the gnome extension package gnome-shell-extension-sound-output-device-chooser installed via dnf. I see that the package is still listed in fedora 35, but apparently it is not supported by the latest version of Gnome and is disabled.

I was under the impression that dnf packages would continue working after an upgrade. If they don’t, they’re removed from the repositories.

I’m not looking for support of everything that’s available at gnome.org, but if something is in the repos I thought I could consider it to be safe to rely on.

Please set me straight on what the policies are. Also, maybe a resource on what I can do to test my extensions before the next upgrade.

Thanks in advance.


If you have paid attention you would know that

  1. Gnome 40+ is still new and F35 is the first release in fedora with gnome 41.
  2. Gnome extensions are not a part of gnome, but are maintained and upgraded by individual maintainers. They do not always keep up with changes in gnome and there may be a lag in upgrades so can be incompatible at times.
  3. Just because packages are installed/upgraded by dnf does not mean they are always in sync. Those that are part of the distro are kept in sync as far as possible. Those that are maintained and packaged separately, even though provided by the main repo, may not always be kept in sync.

You have the same access as everyone else. Fedora maintained packages are typically kept in sync. Separately maintained packages my not always be in sync.

If you have specific packages/extensions that you rely on then maybe you could directly contact the maintainers of those packages and help in doing testing and validating the updates so they can be kept more closely in sync with everything else in the repo.

1 Like

Note that missing support doesn’t mean the extension cannot work.
Many extensions work fine if you just disable compatibility check:


You could try this: manually change extensions to make them work in F35, with Gnome 41. (do not know if it works with all systems and extensions)
cd .local/share/gnome-shell/extensions/
ls or exa (find the extension name )
cd [extension name]
nano metadata.json
change by adding ,“41” (comma + Gnome version number)

"shell-version": [

(could be you need root permissions)
and reboot to enable the extension.

1 Like

Thank you for the details on how to work around the problem. I will open issues where none exist.

My real commentary here is that the user experience here is quite poor. What can be done to improve it for the next upgrade? I don’t know what is already being done on this front so here are some questions:

Does the fedora project open issues with upstream extensions to support the latest version of Gnome? As far as I know there are only a dozen or so packages in the repos so this shouldn’t be a huge task.

How long is the time window between a Gnome release and a Fedora upgrade? Is reasonable to expect upstream to address an issue before an upgrade?

What suggestions do you folks have on this topic?


As general rule when using Gnome desktop when a newer version comes out most extensions won’t work.Thats not Fedora or Gnome’s fault as most extensions are developed but other sources.It maybe just one person developing an extension in there spare time for free.I use the Gnome shell extensions add on for the browser so I can see when a new version of an extension I like is released or updated to support the latest Gnome release.

1 Like
> dnf -q repoquery -s \
$(dnf -q --latest-limit=1 \
repoquery gnome-shell-extension-\*) \
| wc -l

I agree with you because a repository has something to do with trust into a product. I also suggest that all incompatible extension should be removed until the upstream version is updated and verified. Gnome.org extension is the opposite of a repository because there it’s the wild of software without any guarantee. Workarounds are always a bad thing because their main purpose is to override a malfunction.


Yeah, I do feel like if extensions that we ship in the repo as RPMs aren’t updated by the final release freeze, we should probably drop them from the repository. That’s not great but it’s better than shipping broken extensions. This is probably something to bring up with the Fedora Workstation team in their overall issue tracker at Issues - fedora-workstation - Pagure.io


Most extensions actually work, the only problem is the compatibility manifest.
It takes some time for developers and maintainers to update and test them.

I’m very glad that we have people packaging popular extensions.
And I’m deeply disappointed that some ungrateful users want to destroy this.

You can just use extensions.gnome.org, you don’t need to install packages.
Please stop breaking things that work for others.

1 Like

@vgaetera: Come on, is this kind of posting really necessary?

I agree with you, this strategy will force to stop unnecessary issues and it should be done for all “outdated” packages and it will make Fedora more reliable than ever before.

“Destroy” seems unnecessarily harsh. I don’t see anyone who doesn’t want things to get better, just different approaches about how to get there.

I agree it’s nice to have these packaged up, but if people take that approach, they should test and update the extension to match the release. Otherwise, what’s the point?

Removing extension packages instead of updating them doesn’t sound harsh for you?
Perhaps some people should direct their excessive energy to positive activities instead of destructive ones.

@vgaetera Follow your own advise and bring it up.

Your concern is irrelevant as I file the proper tickets for issues affecting me.
I do not demand the removal of a package just because it is slightly outdated at the time of the new release.
This is usually fixed sooner rather than later and then works fine until the next release.

1 Like

Well, to me, it seems like having packages there which aren’t adequately maintained is “destructive” in a way, because it results in a broken overall experience for users.

I honestly don’t quite get where you’re coming from; you say:

… but it’s the packages that are broken. They’re not just working.

I do agree that it’d be great to have more volunteers maintaining the various extension packages and making sure they work. We encourage comaintainership. But where extensions don’t work… they should be dropped. That would happen basically automatically if the packages used a binary language and failed to build from scratch; it’s really just a quirk that they can be installed but be broken.


gnome extensions on Fedora are quite a unique situation.

Since Fedora gets gnome releases basically as soon as they are available, most extensions will be broken for a short-time after a new release.

Dropping all those packages and then re-adding them as compatibility is fixed feels like a strange thing to do although it may be technically correct.

I’m open to other ideas. I’d love to see an upstream effort to get extensions updated more quickly. The GNOME 41 rc came out on September 8, almost two months before F35 came out. For extensions that many people depend on, there should be enough interest to make that work.

1 Like

I guess would possibility would be: make RPM extract compatibility from metadata.json in each extension, for example

  "shell-version": [

for gnome-shell-extension-sound-output-device-chooser, and generate automatic dependencies on the gnome-shell version. Then, on upgrade, if these packages are installed but not updated, you’d get transaction errors and could decide to remove them with --allow-erasing — or decide to delay upgrading.

1 Like