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

Android Leftovers

BlackWeb 1.2

BlackWeb is a penetration and security testing distribution based on Debian. The project's website presents the distribution's features as follows: BlackWeb is a Linux distribution aimed at advanced penetration testing and security auditing. BlackWeb contains several hundred tools which are geared towards various information security tasks, such as penetration testing, security research, computer forensics and reverse engineering. Starting from an appropriately configured LXDE desktop manager it offers stability and speed. BlackWeb has been designed with the aim of achieving the maximum performance and minimum consumption of resources. There are 32-bit (x86) and 64-bit (x86_64) builds of BlackWeb available on the distribution's website. I downloaded the 64-bit build which is 2.6GB in size. Booting from the media brings up a menu asking if we would like to try BlackWeb's live desktop, run the installer or run the graphical installer. Taking the live desktop options presents us with a graphical login screen where we can sign in with the username "root" and the password "blackweb". Read more

Feh is a light-weight command-line image viewer for Linux

The default image viewer in most Linux distros is a fine option for many users, but if you want a distraction free alternative, Feh is a good option. Feh's interface is as barebones as it gets as it does not have any toolbars or buttons but is a command line interface application; because of that, it is very light on resources and still easy enough to use even for users who shy away from using the command line whenever possible. Read more

Free as in Sausage Making: Inside the Debian Project

Recently, we’ve been having some discussion around the use of non-free software and services in doing our Debian work. In judging consensus surrounding a discussion of Git packaging, I said that we do not have a consensus to forbid the use of non-free services like Github. I stand behind that consensus call. Ian Jackson, who initially thought that I misread the consensus later agreed with my call. I have been debating whether it would be wise for me as project leader to say more on the issue. Ultimately I have decided to share my thoughts. Yes, some of this is my personal opinion. Yet I think my thoughts resonate with things said on the mailing list; by sharing my thoughts I may help facilitate the discussion. We are bound together by the Social Contract. Anyone is welcome to contribute to Debian so long as they follow the Social Contract, the DFSG, and the rest of our community standards. The Social Contract talks about what we will build (a free operating system called Debian). Besides SC #3 (we will not hide problems), the contract says very little about how we will build Debian. What matters is what you do, not what you believe. You don’t even need to believe in free software to be part of Debian, so long as you’re busy writing or contributing to free software. Whether it’s because you believe in user freedom or because your large company has chosen Debian for entirely pragmatic reasons, your free software contributions are welcome. I think that is one of our core strengths. We’re an incredibly diverse community. When we try to tie something else to what it means to be Debian beyond the quality of that free operating system we produce, judged by how it meets the needs of our users, we risk diminishing Debian. Our diversity serves the free software community well. We have always balanced pragmatic concerns against freedom. We didn’t ignore binary blobs and non-free firmware in the kernel, but we took the time to make sure we balanced our users’ needs for functional systems against their needs for freedom. By being so diverse, we have helped build a product that is useful both to people who care about freedom and other issues. Debian has been pragmatic enough that our product is wildly popular. We care enough about freedom and do the hard work of finding workable solutions that many issues of software freedom have become mainstream concerns with viable solutions. Read more