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

Red Hat: Application Migration, Departure, OpenShift Commons Gathering and More

  • Application Migration with Container-native virtualization

    More and more frequently, modern applications are choosing a container-first development and deployment paradigm built on the foundation of Kubernetes. However, not all applications are fully modernized and containerized micro services. Many applications are a hybrid of architectures and technology which have existed for years, even decades. This can add complexity, both to the application architecture and management overhead, when a container-based, cloud-native application component needs to access existing functionality which is virtual machine based. Container-native virtualization provides flexibility during the modernization process so that you can focus on the most critical aspects first, while still being able to access, manage, and consume VM-based aspects using the new Kubernetes-centric tools. Based on the KubeVirt project, recently accepted by the CNCF, Container-native virtualization manages both virtual machines and containers through a single control plane saving time, resources, and budget. Red Hat Container-native virtualization delivers KubeVirt functionality directly to OpenShift customers and helps to manage both virtual machines and OpenShift deployments from a single platform. This single platform simplifies the management of virtual machines and containers with a common Kubernetes interface that standardizes orchestration, networking, and storage management while also supporting the long term move to containers.

  • Alberto Ruiz: Hanging the Red Hat

    After 6+ wonderful years at Red Hat, I’ve decided to hang the fedora to go and try new things. For a while I’ve been craving for a new challenge and I’ve felt the urge to try other things outside of the scope of Red Hat so with great hesitation I’ve finally made the jump. I am extremely proud of the work done by the teams I have had the honour to run as engineering manager, I met wonderful people, I’ve worked with extremely talented engineers and learned lots. I am particularly proud of the achievements of my latest team from increasing the bootloader team and improving our relationship with GRUB upstream, to our wins at teaching Lenovo how to do upstream hardware support to improvements in Thunderbolt, Miracast, Fedora/RHEL VirtualBox guest compatibility… the list goes on and credit goes mostly to my amazing team. Thanks to this job I have been able to reach out to other upstreams beyond GNOME, like Fedora, LibreOffice, the Linux Kernel, Rust, GRUB… it has been an amazing ride and I’ve met wonderful people in each one of them.

  • Recap: OpenShift Commons Gathering at Kubecon/NA San Diego [Videos Uploaded]

    The OpenShift Commons Gathering in San Diego brought together over 550+ Kubernetes and Cloud Native experts from all over the world to discuss container technologies, best practices for cloud native application developers and the open source software projects that underpin the OpenShift ecosystem.

  • IBM Kicks Up Kubernetes Compatibility With Open Source

Antoine Beaupré: a quick review of file watchers

File watchers. I always forget about those and never use then, but I constantly feel like I need them. So I made this list to stop searching everywhere for those things which are surprisingly hard to find in a search engine. Read more

Solaris/UNIX: New Solaris Update/Release, Mystery of Unix History

  • Announcing Oracle Solaris 11.4 SRU15

    Today we are releasing SRU 15, the November 2019 SRU, for Oracle Solaris 11.4. It is available via 'pkg update' from the support repository or by downloading the SRU from My Oracle Support Doc ID 2433412.1.

  • Oracle Solaris 11.4 SRU15 Has A Number Of Package Updates

    While there is no sign of Solaris 11.5 or Solaris.Next (last year was a road-map pointing to Solaris 11.Next in H2'19 or H1'20 that has since been removed), Oracle does continue putting out more updates to the Solaris 11.4 series. Oracle Solaris 11.4 SRU 15 was released on Tuesday as the latest monthly update to the Solaris stable series. With Solaris 11.4 SRU 15 are more Python 3 modules being added along with other Python updates, updating the GCC compiler against v9.2, updates to other toolchain bits like CMake, and a wide range of security updates.

  • A Mystery of Unix History

    The two most popular historic editors on Unix, vi and emacs, both make heavy use of these features (Emacs using Esc when Alt or Meta is unavailable). Some of the later entries in the DEC terminal line, especially the vt510, supported key remapping or alternative keyboards, which can address the Esc issue, but not entirely. According to the EmacsOnTerminal page and other research, at least the vt100 through the vt420 lacked Esc by default. Ctrl-3 and Ctrl-[ could send the character. However, this is downright terrible for both vi and Emacs (as this is the only way to trigger meta commands in Emacs). What’s more, it seems almost none of these old serial terminal support hardware flow control, and flow control is an absolute necessity on many. That implies XON/XOFF, which use Ctrl-S and Ctrl-Q — both of which are commonly used in Emacs.

Mesa 19.2.5

Hi list,

I'd like to announce mesa 19.2.5. This is a return to our regularly scheduled
release cadence, featuring a reasonable number of fixes. In general things are
slowing down on the 19.2 branch, and things are starting to look pretty nice.

There's a little bit over everything in here, with anv and radeonsi standing out
as the two biggest components getting changes, but core mesa, core gallium,
llvmpipe, nir, egl, i965, tgsi, st/mesa, spirv, and the Intel compiler also
fixes in this release.

Dylan


Shortlog
========

Ben Crocker (1):
      llvmpipe: use ppc64le/ppc64 Large code model for JIT-compiled shaders

Brian Paul (1):
      Call shmget() with permission 0600 instead of 0777

Caio Marcelo de Oliveira Filho (1):
      spirv: Don't leak GS initialization to other stages

Danylo Piliaiev (1):
      i965: Unify CC_STATE and BLEND_STATE atoms on Haswell as a workaround

Dylan Baker (4):
      docs: Add SHA256 sum for for 19.2.4
      cherry-ignore: Update for 19.2.4 cycle
      docs: Add relnotes for 19.2.5
      VERSION: bump for 19.2.5

Eric Engestrom (1):
      egl: fix _EGL_NATIVE_PLATFORM fallback

Ian Romanick (2):
      nir/algebraic: Add the ability to mark a replacement as exact
      nir/algebraic: Mark other comparison exact when removing a == a

Illia Iorin (1):
      mesa/main: Ignore filter state for MS texture completeness

Jason Ekstrand (1):
      anv: Stop bounds-checking pushed UBOs

Lepton Wu (1):
      gallium: dri2: Use index as plane number.

Lionel Landwerlin (3):
      anv: invalidate file descriptor of semaphore sync fd at vkQueueSubmit
      anv: remove list items on batch fini
      anv/wsi: signal the semaphore in the acquireNextImage

Marek Olšák (3):
      st/mesa: fix Sanctuary and Tropics by disabling ARB_gpu_shader5 for them
      tgsi_to_nir: fix masked out image loads
      tgsi_to_nir: handle PIPE_FORMAT_NONE in image opcodes

Paulo Zanoni (1):
      intel/compiler: fix nir_op_{i,u}*32 on ICL

Pierre-Eric Pelloux-Prayer (3):
      radeonsi: disable sdma for gfx10
      radeonsi: tell the shader disk cache what IR is used
      radeonsi: fix shader disk cache key


git tag: mesa-19.2.5

Read more Also: Mesa 19.2.5 Released With Intel Vulkan + RadeonSI Driver Fixes