#1 Restore the snap plugin
Closed 2 months ago by kalev. Opened 2 months ago by ngompa.
rpms/ ngompa/gnome-software master-restore-snap  into  master

file modified
+32 -3

@@ -9,12 +9,13 @@ 

  %global fwupd_version 1.0.7

  %global flatpak_version 1.1.3

  %global libxmlb_version 0.1.7

+ %global snapd_glib_version 1.48

  

  %global __requires_exclude ^libdnf[.]so[.].*$

  

  Name:      gnome-software

  Version:   3.32.4

- Release:   1%{?dist}

+ Release:   2%{?dist}

  Summary:   A software center for GNOME

  

  License:   GPLv2+

@@ -49,6 +50,11 @@ 

  BuildRequires: rpm-ostree-devel

  BuildRequires: libgudev1-devel

  BuildRequires: valgrind-devel

+ %if 0%{?fedora}

+ # Remove liboauth-devel BR in 3.33.x bump, as it's no longer needed in g-s 3.33

+ BuildRequires: liboauth-devel

+ BuildRequires: snapd-glib-devel >= %{snapd_glib_version}

+ %endif

  

  Requires: appstream-data

  %if 0%{?fedora}

@@ -73,8 +79,6 @@ 

  

  Recommends: PackageKit%{?_isa} >= %{packagekit_version}

  

- Obsoletes: gnome-software-snap < 3.33.1

- 

  # this is not a library version

  %define gs_plugin_version               13

  

@@ -109,12 +113,28 @@ 

  

  This package includes the rpm-ostree backend.

  

+ %if 0%{?fedora}

+ %package snap

+ Summary: Support for Ubuntu Snap packages

+ Requires: %{name}%{?_isa} = %{version}-%{release}

+ Requires: snapd

+ Requires: snapd-glib%{?_isa} >= %{snapd_glib_version}

+ Supplements: (gnome-software%{?_isa} and snapd%{?_isa})

+ 

+ %description snap

+ Adds support for Snap packages from the Snap store.

+ %endif

+ 

  %prep

  %autosetup -p1

  

  %build

  %meson \

+ %if 0%{?fedora}

+     -Dsnap=true \

+ %else

      -Dsnap=false \

+ %endif

      -Dgudev=true \

      -Dpackagekit=true \

      -Dexternal_appstream=false \

@@ -210,6 +230,12 @@ 

  %files rpm-ostree

  %{_libdir}/gs-plugins-%{gs_plugin_version}/libgs_plugin_rpm-ostree.so

  

+ %if 0%{?fedora}

+ %files snap

+ %{_libdir}/gs-plugins-%{gs_plugin_version}/libgs_plugin_snap.so

+ %{_datadir}/metainfo/org.gnome.Software.Plugin.Snap.metainfo.xml

+ %endif

+ 

  %files devel

  %{_libdir}/pkgconfig/gnome-software.pc

  %dir %{_includedir}/gnome-software

@@ -222,6 +248,9 @@ 

  %{_mandir}/man1/gnome-software-editor.1*

  

  %changelog

+ * Sun Jul 14 2019 Neal Gompa <ngompa13@gmail.com> - 3.32.4-2

+ - Restore snap plugin subpackage

+ 

  * Thu Jul 11 2019 Kalev Lember <klember@redhat.com> - 3.32.4-1

  - Update to 3.32.4

  

This PR restores the snap plugin subpackage.

Packaging this separately is burdensome when it is shipped as part of the GNOME Software sources and relies on building all of GNOME Software anyway to do it.

This was already shipped as a subpackage that wasn’t installed by default in the past, and I believe it should be restored. For maintaining the snap plugin subpackage, myself, @zyga (main developer of snapd core), @bboozzoo (main developer of Fedora security enablement of snapd), and/or @rancell (g-s-snap and snapd-glib developer) can be assigned bugs related to the snap plugin. We are willing to assist in the maintenance of this component.

rebased onto a057284

2 months ago

rebased onto 473737c

2 months ago

It was dropped deliberately so that gnome-software maintainers (hughsie and I) wouldn't have to maintain the snap side. Like hughsie said in his email, please put the snap support in a separate source package if you are interested in shipping it. Sorry for causing you more work.

Pull-Request has been closed by kalev

2 months ago

It was dropped deliberately so that gnome-software maintainers (hughsie and I) wouldn't have to maintain the snap side. Like hughsie said in his email, please put the snap support in a separate source package if you are interested in shipping it. Sorry for causing you more work.

But it is kept in upstream… Also Neal volunteered to take care of bugs related to snap. Why to create over-complicated solution instead of just enabling one option back? If plugin would be easily buildable out-of-tree, then sure. But what I saw looked really horrible (build whole gnome-software and drop everything except of plugin).

That's a question to hughsie. I would have liked to drop it upstream as well.

TBH if Ubuntu is switching from GNOME Software to Snap Store... well, Snap Store is not going to install flatpaks.

Currently snaps on Fedora and flatpak on Ubuntu have a sort of software center feature parity: you can install an extra package to make it work in the software center, but neither is going to work by default. It's very important to maintain this parity. Having snaps working with nice GUI integration everywhere but not flatpaks would be a tremendous blow to flatpak.

So it seems extremely important to stop supporting Snaps in our GNOME Software. I'd really prefer not to have a separate package even. We should only continue to support snaps if the Snap Store is going to have flatpak support, which seems almost impossible.

Yep, that's exactly why we're trying to drop the snap plugin. I wanted to drop it upstream (https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/253), but hughsie was against it so we're doing it downstream instead now.

So it seems extremely important to stop supporting Snaps in our GNOME Software. I'd really prefer not to have a separate package even. We should only continue to support snaps if the Snap Store is going to have flatpak support, which seems almost impossible.

Well, we either should not have separate package or we should enable it in gnome-software. We are not hurting snap here by forcing separate source package, but @ngompa. He will have to maintain this horrible hack. If we want to not support snaps in gnome software, then we should not do it at all.

Probably we should bring this to FESCo?

Yes, we should not have snap support. if @ngompa chooses the maintain a hack, that is his choice.

Yes, what mclasen said. Exactly my thoughts.

Probably we should bring this to FESCo?

If we do, FESCo needs to also rule on the new plugins ability to "facilitate" access to patent-encumbered software. If one click and no legal boilerplate is fine, then it's also fine for Flathub.

Yes, we should not have snap support. if @ngompa chooses the maintain a hack, that is his choice.

This is not how we are supposed to work together. We are distribution which tries to accomodate requirements from different people.

If we do, FESCo needs to also rule on the new plugins ability to "facilitate" access to patent-encumbered software. If one click and no legal boilerplate is fine, then it's also fine for Flathub.

Sure, let's have a discussion. Mind opening a ticket?

Normally legal issues go to Spot, not to FESCo.

Also, normally FESCo makes technical decisions to solve technical problems. This is not really a technical problem, though. It's a strategic issue for both Silverblue and Fedora Workstation. A good technical solution to this problem would actually create serious risk for our strategic plan. Please keep this in mind.

It's a strategic issue for both Silverblue and Fedora Workstation

From https://docs.fedoraproject.org/en-US/fesco/:

  • Package maintainer disputes
  • Responsible for what software is offered to end users under what conditions.

Also this plugin is NOT installed with gnome-software unless snapd is installed. And snapd is not installed on silverblue / workstation by default. It even lives in its own subpackage... So what is exactly the problem with this?

Currently snaps on Fedora and flatpak on Ubuntu have a sort of software center feature parity: you can install an extra package to make it work in the software center, but neither is going to work by default. It's very important to maintain this parity. Having snaps working with nice GUI integration everywhere but not flatpaks would be a tremendous blow to flatpak.

Let's not shoot ourselves in the foot, please.

Probably we should bring this to FESCo?

If we do, FESCo needs to also rule on the new plugins ability to "facilitate" access to patent-encumbered software. If one click and no legal boilerplate is fine, then it's also fine for Flathub.

Is the one click referring to installing the snap plugin? The user would need to choose to install that as it is not installed by default in Fedora.

and/or @rancell (g-s-snap and snapd-glib developer) can be assigned bugs related to the snap plugin. We are willing to assist in the maintenance of this component.

Just confirming that bugs relating to the snap plugin in Fedora (or other distros) can be filed against gnome-software or snapd-glib and I'll do my best to fix them!

@rancell Would you also be willing to accept comaintainer or bugwatcher for the Fedora packages for gnome-software and snapd-glib so Red Hat Bugzilla bugs reach you automatically?

@rancell Would you also be willing to accept comaintainer or bugwatcher for the Fedora packages for gnome-software and snapd-glib so Red Hat Bugzilla bugs reach you automatically?

I'm happy to be a bugwatcher for snapd-glib since any bugs there are of interest to me. I think that gnome-software is less useful - I'm more likely to miss the snap related bugs in there with all the other bug email I get. If they're reported upstream I'll see them and I'm happy to be linked into any RH bugs that refer to snaps.