Language Selection

English French German Italian Portuguese Spanish

A Merge Proposal to ‘Drop Snap Support’ from GNOME Software Hints at Deeper Divisions

Filed under
GNU
Linux
GNOME
Ubuntu

As you probably know, Ubuntu Software, the default software app Ubuntu ship with, is based on GNOME Software. It’s mostly the same app save for a few Snap-specific tweaks (which we’ve mentioned before) and shipping with the Snap plugin by default.

In short, the “Snap” support it offers isn’t particularly egregious or wide-reaching.

But word on the street is that Ubuntu is prepping a brand new app store exclusively tailored to Snap apps for use in a future release (but separate from the Snap’d Snap Store snap)

This has made some devs who work on GNOME Software a little …twitchy.

Kalev Lember, the dev behind the merge request to nuke the 4000 or so lines of Snap support in GNOME Software, explains:-

“Ubuntu is switching to a new snap-store app for installing and removing snaps. This commit drops the snap backend from gnome-software to avoid maintenance overhead.”

Reasonable. Why should they shoulder the burden of working around Snap-specific code if Ubuntu, the only distro making use of it, don’t plan to use it longterm?

Read more

More on this feud

  • GNOME Software Moving Forward With Disabling Snap Plugin

    While currently Ubuntu makes use of GNOME Software as their "software center" (or "app store") with Snap integration, as we wrote about recently Canonical has begun writing their own Snap Store. Given this and that they don't plan to use GNOME Software in Ubuntu 20.04 LTS and thus have taken their developers away from working on the upstream support, GNOME developers are planning to disable the Snap plug-in for GNOME Software.

  • Heads up: No more snap plugin in gnome-software

    In Fedora 31 I'll be disabling the snap plugin from GNOME Software. It's never been enabled in RHEL and so this change only affects Fedora. It's also not installed by default and so this change should only affect a few people. It's also not really a FutureFeature, it's a RemovalOfFeature but I'm happy to write something for the process and release notes if required. Recently Canonical decided that they are not going to be installing gnome-software in the next LTS, preferring instead to ship a "Snap Store by Canonical" rather than GNOME Software. The new Snap store will obviously not support Flatpaks (or packages, or even firmware updates for that matter). The developers currently assigned to work on gnome-software have been reassigned to work on Snap Store, and I'm not confident they'll be able to keep both the old and new codebases in the air at the same time.

  • EFF Celebrating 29th Birthday with $20 Membership, Linode Launches New GPU-Optimized Cloud Computing Instances, Syncthing 1.2.0 Released, Kali Linux Now Available for RPi 4 and GNOME Devs to Disable Snap Plugin for GNOME Software

    GNOME developers plan to disable the Snap plugin for GNOME Software, as Canonical has started creating its own Snap Store and won't be using GNOME Software in Ubuntu 20.04 LTS. According to Phoronix, "Canonical's in-development Snap Store will obviously be focused just on their own Snap effort and not supporting the likes of Flatpak. Due to the likelihood that the GNOME Software Snap plug-in will quickly suffer from bit-rot and pose a maintenance burden to GNOME developers with little to no return, it's certainly reasonable that they would at least disable this plug-in."

On it goes

  • Fedora is ‘Disabling’ the Snap Plugin for GNOME Software

    The Snap plugin for GNOME Software is being ‘disabled’ in Fedora 31, the distro’s next major release.

    Red Hat’s Richard Hughes announced the change on the Fedora developer mailing list, citing various issues with the plugins QA and long-term usefulness.

    Neal Gompa, who maintains the Snap package in Fedora, says the decision has “blindsided” him.

    So why is Fedora doing this?

    Well, code quality and concerns about the impact the plugin has on the overall GNOME Software user experience are cited:

Fedora To Disable Snap Plugin For GNOME Software

  • Fedora To Disable Snap Plugin For GNOME Software

    We recently saw a merge proposal from Canonical to replace gnome-software snap with their own Snap Store. Along the similar lines, Red Hat’s Richard Hughes has announced that Fedora will disable snap plugin for GNOME Software. His announcement comes just a day after this.

    Fedora will disable the snap plugin in its next major update release, according to Hughes. He mentions that the existing snap plugin is not very well tested and it causes general UX of GNOME software to degrade.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Debian: CUPS, LTS and Archival

  • Praise Be CUPS Driverless Printing

    Last Tuesday, I finally got to start updating $work's many desktop computers to Debian Buster. I use Puppet to manage them remotely, so major upgrades basically mean reinstalling machines from scratch and running Puppet. Over the years, the main upgrade hurdle has always been making our very large and very complicated printers work on Debian. Unsurprisingly, the blog posts I have written on that topic are very popular and get me a few 'thank you' emails per month. I'm very happy to say, thanks to CUPS Driverless Printing (CUPS 2.2.2+), all those trials and tribulations are finally over. Printing on Buster just works. Yes yes, even color booklets printed on 11x17 paper folded in 3 stapled in the middle.

  • Freexian’s report about Debian Long Term Support, August 2019

    Like each month, here comes a report about the work of paid contributors to Debian LTS.

  • Louis-Philippe Véronneau: Archiving 20 years of online content

    mailman2 is pretty great. You can get a dump of an email list pretty easily and mailman3's web frontend, the lovely hyperkitty, is well, lovely. Importing a legacy mailman2 mbox went without a hitch thanks to the awesome hyperkitty_import importer. Kudos to the Debian Mailman Team for packaging this in Debian for us. But what about cramming a Yahoo! Group mailing list in hyperkitty? I wouldn't recommend it. After way too many hours spent battling character encoding errors I just decided people that wanted to read obscure emails from 2003 would have to deal with broken accents and shit. But hey, it kinda works! Oh, and yes, archiving a Yahoo! Group with an old borken Perl script wasn't an easy task. Hell, I kept getting blacklisted by Yahoo! for scraping too much data to their liking. I ended up patching together the results of multiple runs over a few weeks to get the full mbox and attachments. By the way, if anyone knows how to tell hyperkitty to stop at a certain year (i.e. not display links for 2019 when the list stopped in 2006), please ping me.

Running The AMD "ABBA" Ryzen 3000 Boost Fix Under Linux With 140 Tests

Last week AMD's AGESA "ABBA" update began shipping with a fix to how the boost clock frequencies are handled in hopes of better achieving the rated boost frequencies for Ryzen 3000 series processors. I've been running some tests of an updated ASUS BIOS with this adjusted boost clock behavior to see how it performs under Linux with a Ryzen 9 3900X processor. The AGESA 1.0.0.3 ABBA update has an improved boost clock frequency algorithm along with changes to the idle state handling. This AGESA update should better position AMD Ryzen 3000 processors with the boost clock behavior expected by users with better hitting the maximum boost frequency and doing so more aggressively. Read more

Stable kernels 5.2.16, 4.19.74, and 4.14.145

  • Linux 5.2.16
    I'm announcing the release of the 5.2.16 kernel. All users of the 5.2 kernel series must upgrade. The updated 5.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.2.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-s...
  • Linux 4.19.74
  • Linux 4.14.145

Linux Container Technology Explained (Contributed)

State and local governments’ IT departments increasingly rely on DevOps practices and agile development methodologies to improve service delivery and to help maintain a culture of constant collaboration, iteration, and flexibility among all stakeholders and teams. However, when an IT department adopts agile and DevOps practices and methodologies, traditional IT problems still need to be solved. One long-standing problem is “environmental drift,” when the code and configurations for applications and their underlying infrastructure can vary between different environments. State and local IT teams often lack the tools necessary to mitigate the effects of environmental drift, which can hamper collaboration and agility efforts. Read more