12:34 p.m.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The flatpak remote for Flathub will have no filtering, making all the
Flathub content available in GNOME Software and via the flatpak
commandline.
== Owner ==
* Name: Workstation WG
* Email: mclasen(a)redhat.com
== Detailed Description ==
Fedora includes a flatpak repo definition for Flathub in the
fedora-flathub-remote package. So far, this remote
was filtered by an allowlist that only made a limited subset of
software from Flathub available. We've been told
that it is ok for us to remove the filtering and make all of Flathub available.
The filtering mechanism itself will still be there, and it will be
possible for us to reinstate a filter via a package
update, should the need arise in the future.
The Flathub remote is available to users who opt-in to enabling
third-party software repositories in either GNOME Initial Setup or
GNOME Software. Users who do not opt in will not see anything from
Flathub.
In case of overlaps, GNOME Software will prefer Fedora flatpaks over
Flathub flatpaks. It is always possible for the user to manually
select a different source for individual applications.
== Feedback ==
This change proposal has previously been discussed here:
https://pagure.io/fedora-workstation/issue/300
== Benefit to Fedora ==
More software will be easily available to Fedora users.
Additionally, the filtered Flathub has not been popular with users.
Users have been confused and displeased that our Flathub remote
contains only a small subset of Flathub, rather than the full Flathub.
Dropping the filter will resolve this criticism.
== Scope ==
* Proposal owners: Remove the allowlist in
/usr/share/flatpak/fedora-flathub.filter, or replace it with one that
allows everything
* Other developers: GNOME Software developers: Verify that the
priorities between repos and packaging formats work out as desired
* Release engineering: No work needed
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Existing Fedora installations with a configured Fedora Flathub remote
will pick up the new, permissive filter.
== How To Test ==
When third-party software is not enabled in GNOME Initial Setup or
GNOME Software, search results from Flathub should not appear in GNOME
Software.
When third-party software is enabled in GNOME Initial Setup or GNOME
Software, search results from Flathub should appear.
== User Experience ==
When opening GNOME Software, all the applications that are available
on Flathub will show up in search results.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: Reinstate the filtering we had in Fedora 36
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md
fedora-third-party]
* [https://github.com/flathub/flathub/wiki Flathub wiki]
* [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remo...
Comparison of Fedora Flatpaks and Flathub remotes]
== Release Notes ==
The Fedora Flathub remote now exposes all content from Flathub,
instead of only a small subset. Flathub is not enabled by default. To
enable software from Flathub, turn on third-party software in GNOME
Initial Setup or GNOME Software.
--
Vipul Siddharth
He/His/Him
FPgM team member
1:06 p.m.
On 29/06/2022 19:34, Vipul Siddharth wrote:
The flatpak remote for Flathub will have no filtering, making all
the
Flathub content available in GNOME Software and via the flatpak
commandline.
Strongly -1, because Flatpaks have higher priority over RPMs in Gnome
Software.
1. GNOME Software need to be patched to prefer RPMs over Flatpaks for
non-ostree Fedora variants, because it will replace Fedora packages with
Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for
Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM"
for Silverblue/Kinoite will be better.
2. Fedora shouldn't rely on low-quality third-party repository. A lot of
Flathub packages even doesn't built from sources on trusted infra:
Firefox, OBS Studio, Blender, Element, Signal, etc. They just repackage
DEBs or static binaries:
-
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signa...
-
https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98...
-
https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Bl...
Firefox and OBS Studio even uploaded as a pre-built ostree blob.
3. "Sandboxing" is the biggest lie. A lot of apps have
--filesystem={home,host} in manifests:
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:25 p.m.
On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
1. GNOME Software need to be patched to prefer RPMs over Flatpaks
for
non-ostree Fedora variants, because it will replace Fedora packages
with
Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for
Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM"
for Silverblue/Kinoite will be better.
GNOME Software already has a hidden setting for this:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a0...
It defaults to Flatpaks because they are sandboxed and are much safer
than unsandboxed applications.
However, I believe Flatpaks built from Fedora RPMs should take
precedence over Flatpaks built from Flathub. Flathub should only be
preferred when there is no Fedora Flatpak available.
Michael
1:41 p.m.
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all
non-ostree Fedora variants (Workstation, Spins).
When the Flathub filtering is removed, most Fedora packages will be
silently replaced by Flatpaks, some of them very low quality (DEB
rebuids) because the Flathub versions are always greater than in Fedora.
It defaults to Flatpaks because they are sandboxed and are much safer
than unsandboxed applications.
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
However, I believe Flatpaks built from Fedora RPMs should take
precedence over Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page:
https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Flathub should only be preferred when there is no Fedora Flatpak
available.
I don't see it in the proposal.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:52 a.m.
On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
> GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all
non-ostree Fedora variants (Workstation, Spins).
Flatpak should come first as that
what will be used in the long term.
When the Flathub filtering is removed, most Fedora packages will be
silently replaced by Flatpaks, some of them very low quality (DEB
rebuids) because the Flathub versions are always greater than in
Fedora.
> It defaults to Flatpaks because they are sandboxed and are much
> safer than unsandboxed applications.
-
https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
-
https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
> However, I believe Flatpaks built from Fedora RPMs should take
> precedence over Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page:
https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Can we investigate why is the case, its not like the packages in the
repo cannot be package as flatpak. We could be crafty here as we can
control extensions too (and can patch application if needed). I mean
fedora silverblue 36 was shipping with gnome 41 apps on release.
Maybe have fedora flatpak for certain popular applications(which can be
flatpaked) as a blocker for this proposal.
> Flathub should only be preferred when there is no Fedora Flatpak
> available.
I don't see it in the proposal.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
Thanks & Regards,
Marc Pervaz Boocha
3:07 a.m.
On Wed, Jun 29, 2022 at 08:41:51PM +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
> GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all
non-ostree
Fedora variants (Workstation, Spins).
When the Flathub filtering is removed, most Fedora packages will be silently
replaced by Flatpaks, some of them very low quality (DEB rebuids) because
the Flathub versions are always greater than in Fedora.
> It defaults to Flatpaks because they are sandboxed and are much safer
> than unsandboxed applications.
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
> However, I believe Flatpaks built from Fedora RPMs should take precedence over
Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page:
https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
^^^^ The link above says '3' for F36 Flatpaks
Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Comparing the raw number of RPMs v Flatpaks is not very relevant,
because the count for RPMs includes every single library, cli
tool, graphical app, whatever, while Flatpaks only count the
graphical apps, not the building blocks they comprise.
Better to compare Flatpaks to the number of RPMs containing
a .desktop file. None the less, I expect it would still show
that Flatpaks are the minority of Fedora deliverables.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:18 a.m.
Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
> GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for
all
non-ostree Fedora variants (Workstation, Spins).
+1. Native packages ought to be preferred over random repackaged binaries
from untrusted infrastructure (see the links posted by Vitaly for proof).
Users of RPM-based variants will expect the default package manager to
install RPMs, not Flatpaks, or they would have chosen a Flatpak-based
variant.
Kevin Kofler
4:35 a.m.
On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
<siddharthvipul1(a)gmail.com> wrote:
== Detailed Description ==
Fedora includes a flatpak repo definition for Flathub in the
fedora-flathub-remote package. So far, this remote
was filtered by an allowlist that only made a limited subset of
software from Flathub available. We've been told
that it is ok for us to remove the filtering and make all of Flathub available.
Given that flathub provides similar / overlapping content compared to
RPMFusion (or often, even more "legally problematic" than what's
available from RPMFusion, i.e. prebuilt blobs), doesn't this same
reasoning also apply there? I.e. can Fedora enable the full rpmfusion
repositories by default, as well, instead of only the separate
("filtered") repositories for the proprietary NVidia drivers and the
Steam client?
Fabio
4:40 a.m.
On Wednesday, 29 June 2022 at 20:25, Michael Catanzaro wrote:
On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
> 1. GNOME Software need to be patched to prefer RPMs over Flatpaks for
> non-ostree Fedora variants, because it will replace Fedora packages with
> Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak"
for
> Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora
RPM"
> for Silverblue/Kinoite will be better.
GNOME Software already has a hidden setting for this:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a0...
It defaults to Flatpaks because they are sandboxed and are much safer than
unsandboxed applications.
... *when* they are sandboxed ...
Unfortunately, in many cases, they aren't.
However, I believe Flatpaks built from Fedora RPMs should take
precedence
over Flatpaks built from Flathub. Flathub should only be preferred when
there is no Fedora Flatpak available.
+1
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
4:43 a.m.
Michael Catanzaro wrote:
However, I believe Flatpaks built from Fedora RPMs should take
precedence over Flatpaks built from Flathub. Flathub should only be
preferred when there is no Fedora Flatpak available.
That is not a solution, because Fedora Flatpaks are effectively an abandoned
feature, as evidenced by the next thread, which points out that a required
tool was removed from the repository more than 6 months ago.
We need Fedora RPMs to take precedence over Flatpaks built from Flathub, not
just Flatpaks built from Fedora RPMs.
Kevin Kofler
5:16 a.m.
On 30/06/2022 11:35, Fabio Valentini wrote:
I.e. can Fedora enable the full rpmfusion
repositories by default, as well, instead of only the separate
("filtered") repositories for the proprietary NVidia drivers and the
Steam client?
They don't want to answer why they can't preload RPM Fusion:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
LWN news article: https://lwn.net/Articles/897793/
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:22 a.m.
On 30/06/2022 09:52, Marc Pervaz Boocha via devel wrote:
Flatpak should come first as that what will be used in the long term.
RPM is the main packaging format for Fedora.
Can we investigate why is the case, its not like the packages in the
repo cannot be package as flatpak.
Fedora Flatpak packages are hack-built from RPM modules.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:33 a.m.
Users of RPM-based variants will expect the default package manager
to install RPMs,
not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that
one.
That being said, what about allowing users to set this preference by themselves?
I also think that the repository information should also be made more visible;
if a package is available from multiple sources, gnome-software will display
a separate search entry for each of those, which looks very odd from a UX
perspective - I'd expect some kind of match-by-id to be performed and
for duplicated packages to either be merged into a single button,
or to have some additional bit of text on them telling me which one
comes from where.
Btw, shouldn't gnome-sofware pull in PackageKit?
I typically only use dnf, so I installed gnome-software and it was unusable
until I manually installed PackageKit as well.
A.FI.
5:39 a.m.
On Thursday, 30 June 2022 at 09:52, Marc Pervaz Boocha via devel wrote:
On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
> On 29/06/2022 20:25, Michael Catanzaro wrote:
> > GNOME Software already has a hidden setting for this:
>
> Yes and it should be configured to "['RPM', 'flatpak']"
for all
> non-ostree Fedora variants (Workstation, Spins).
Flatpak should come first as that what will be used in the long term.
That's not true for all editions. I guess you mean GNOME/Workstation
here. I'm not the only one here who's convinced that flatpaks are the
wrong way to package software, so please don't assume whatever the
Workstation WG is doing with flatpaks will be picked up by other
editions.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
5:40 a.m.
On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
<siddharthvipul1(a)gmail.com> wrote:
Given that flathub provides similar / overlapping content compared to
RPMFusion (or often, even more "legally problematic" than what's
available from RPMFusion, i.e. prebuilt blobs), doesn't this same
reasoning also apply there? I.e. can Fedora enable the full rpmfusion
repositories by default, as well, instead of only the separate
("filtered") repositories for the proprietary NVidia drivers and the
Steam client?
Note that the proposal is not about enabling Flathub, only about its filtering. As far as
I understand it remains off by default.
But RPMfusion was my first thought , too. We don't even ship the repo definitions, do
we, and enabling "third party software" in Gnome software center does not enable
RPMfusion. Why not?
My second thought was about packaging. Why should I inverst my free time into rpm
packaging, especially unbundling, caring about dependent packages etc. - i.e. evreything
which makes a distro a distro - when the preferred "packaging" switches to
flatpaks?
"Additionally, the filtered Flathub has not been popular with users.
[...]
Dropping the filter will resolve this criticism."
While we do our packaging work *for* the users, that argument really doesn't convice
me. Give them "curl | sudo sh" because it's so simple and provides more
applications? Let npm and cargo and pip install right into /usr? Much easier and so many
apps! What could go wrong?
5:42 a.m.
On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by
themselves?
+1. Let's let users make choices, not choose for them.
Gnome Software should explicitly ask the user to select a package source
before starting installation.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:27 a.m.
On Thu, 30 Jun 2022 at 10:41, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
... *when* they are sandboxed ...
Unfortunately, in many cases, they aren't.
I don't think that "some apps have lots of holes punched in the
sandbox, but can be locked down easily using a GUI tool, where the
majority are indeed locked down" can reasonably be compared to the
distro packages that are never run in sandboxes and cannot be locked
down in the same way. By that logic we should remove all distro
applications because they can't be locked down or sandboxed by the
user in any meaningful way.
As the person who's been driving AppStream to make desktop
applications easier to install on Linux for the last decade (!) I can
tell you that flatpaks are in almost all cases what users should be
using. By any metric (e.g. live updates, portals, sandboxing,
per-user/per-system) they blow apps-as-packages out of the water. Use
packaged versions of your apps if you want to, but please don't veto a
feature that 99.99% of Fedora users categorically should be using.
Richard
6:54 a.m.
On 30/06/2022 12:40, Michael J Gruber wrote:
Note that the proposal is not about enabling Flathub, only about its
filtering. As far as I understand it remains off by default.
Flathub is already preloaded and enabled by default, but filtered. Now
they want to remove this filter.
This will make the Fedora packagers work useless, because GNOME Software
will always prefer Flathub packages.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:10 a.m.
On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
> That being said, what about allowing users to set this preference by themselves?
+1. Let's let users make choices, not choose for them.
Gnome Software should explicitly ask the user to select a package source
before starting installation.
"Explicitly" is maybe too much. I'd imagine a single slider (or
drop-down menu or whatever) that says "rpm", "flatpak from flathub",
"flatpak from …" when there's more than one choice, with the default
selected by the global preference.
Zbyszek
7:18 a.m.
On Thu, Jun 30, 2022 at 8:11 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
> On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
> > That being said, what about allowing users to set this preference by
themselves?
>
> +1. Let's let users make choices, not choose for them.
>
> Gnome Software should explicitly ask the user to select a package source
> before starting installation.
"Explicitly" is maybe too much. I'd imagine a single slider (or
drop-down menu or whatever) that says "rpm", "flatpak from flathub",
"flatpak from …" when there's more than one choice, with the default
selected by the global preference.
I want GNOME Software to prefer Fedora sources before third party
ones. For me, I also would prefer RPM > Flatpak, because I don't like
the experience I've had with Flatpaks and Flathub, but that's a
different preference.
GNOME Software should always offer Fedora content first, because it's
first-party. If a Fedora RPM and a Flathub Flatpak are on the table,
it should prefer to offer the Fedora RPM.
GNOME Software should not be implicitly discouraging the Fedora
community's efforts.
Keep in mind the alternative to people packaging RPMs isn't that they
do something else, it's that they stop contributing entirely.
--
真実はいつも一つ！/ Always, there's only one truth!
7:20 a.m.
Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by
themselves?
That would make a lot of sense indeed (though the default would still need
to be agreed on). But unfortunately, asking for any kind of user preference
to be added to a GNOME application is usually a lost cause. GNOME has a
strict "take it or leave it" policy.
Kevin Kofler
7:22 a.m.
Richard Hughes wrote:
As the person who's been driving AppStream to make desktop
applications easier to install on Linux for the last decade (!) I can
tell you that flatpaks are in almost all cases what users should be
using. By any metric (e.g. live updates, portals, sandboxing,
per-user/per-system) they blow apps-as-packages out of the water. Use
packaged versions of your apps if you want to, but please don't veto a
feature that 99.99% of Fedora users categorically should be using.
You are conveniently ignoring the drawbacks of the approach, see, e.g.:
http://flatkill.org/
and that is by no means a complete list.
Kevin Kofler
8:50 a.m.
On 30/06/2022 14:22, Kevin Kofler via devel wrote:
You are conveniently ignoring the drawbacks of the approach, see,
e.g.:
http://flatkill.org/
and that is by no means a complete list.
See also: https://ludocode.com/blog/flatpak-is-not-the-future
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:53 a.m.
On 30/06/2022 14:18, Artur Frenszek-Iwicki wrote:
Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.
Too complicated for the average user. It should be visible when you
click the "Install" button.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:18 a.m.
Too complicated for the average user.
That's debatable.
Does the *average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.
It should be visible when you click the "Install" button.
I agree that the current placement makes the source dropdown
not very visible and easy to miss. I was thinking if having some
kind of combo-button (i.e. button + dropdown) would be a
better option - something like:
+ ------------------+---+
| Install | |
| (From Fedora RPM) | v |
+-------------------+---+
This would make the selected source prominent
and allow to easily switch to a different one.
Either way, this is all a UX discussion, and with
GNOME's take-it-or-leave-it approach, I fear
we'd have to patch gnome-software to achieve
something like the above, which would probably
create a lot of maintenance burden.
A.FI.
9:23 a.m.
Please remember that Flathub remains disabled by default even if this
change proposal is fully implemented. It's gated behind the "enable
third-party software?" switch. So if you only want free software from
Fedora, you'll just leave that switch off and never see anything from
Flathub. (In fact, enabling it by default would actually be prohibited
by previous FESCo and Fedora Council decisions.) But users who do
choose enable third-party software really want to see Flathub
unfiltered, not our confusing and annoying limited view of Flathub.
On Thu, Jun 30 2022 at 11:18:04 AM +0200, Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
Users of RPM-based variants will expect the default package manager
to
install RPMs, not Flatpaks, or they would have chosen a Flatpak-based
variant.
Any such expectations are misplaced. The people working on Silverblue
do not feel that it is ready to become Fedora Workstation yet, but
Flatpaks are certainly ready and there's no need to wait. Various
discussions about using more flatpaks:
https://pagure.io/fedora-workstation/issue/151 (resolved long ago)
https://pagure.io/fedora-workstation/issue/269 (next up)
https://pagure.io/fedora-workstation/issue/300 (this change proposal)
I take a pretty dim view towards arguments about "Flathub is untrusted"
and "Flathub packaging is poor" since proponents of these arguments
conveniently ignore the fact that traditional RPMs are totally
unsandboxed. One memory safety bug and your PDF reader, video player,
or other native app has full control of your user account and can do
whatever it wants with all your files. And Linux apps have *lots* of
memory safety bugs. With the exception of web browsers (all of which
have strong sandboxes), few other apps are even trying to sandbox
themselves. I'm not too interested in rehashing the same old arguments
about this because it has all been well-known and said many, many, many
times before. (Yes, system libraries are generally safer than bundled
libraries. No, this is not anywhere near as important as having a
strong sandbox. Yes, many apps on Flathub sabotage the sandboxing to
the point where it is meaningless, and yes that should be discouraged
harder somehow.)
Opponents of Flatpak have had seven years since Flatpak launched to
figure out an alternative model to make apps safe using firejail or
bwrap or whatever, but nobody ever seriously did, and at this point the
endgame has arrived with a *commanding* lead in favor of Flatpak. So
it's time to move on.
Having third-party Flatpaks take precedence over Fedora RPMs that
nobody has bothered to Flatpak is a very intentional choice to improve
user safety (again, only if users opt-in to third-party software). But
you can ensure the Fedora version of an app takes precedence by
creating a Fedora Flatpak for it. And users ultimately have full
control over which source they use to install.
Regardless, Fedora will still be RPM-based no matter what. ;) Even if
our future is OS images composed of RPMs plus Flatpaks composed by
RPMs, it's still based on RPMs. (Of course stuff from Flathub is not
based on RPMs, but we wouldn't expect third-party stuff to be.)
Michael
9:44 a.m.
On Thu, Jun 30 2022 at 12:16:09 PM +0200, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
They don't want to answer why they can't preload RPM Fusion:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
You actually linked straight to the answer. Matthew's response there is
not some passing speculation; that's the real answer based on
discussion with Fedora Legal.
Michael
9:49 a.m.
On 30/06/2022 16:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is
untrusted"
and "Flathub packaging is poor" since proponents of these arguments
conveniently ignore the fact that traditional RPMs are totally unsandboxed.
I would prefer a non-sandboxed app instead of a third-party DEB repack.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:50 a.m.
On 30/06/2022 16:18, Artur Frenszek-Iwicki wrote:
That's debatable. Does the*average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.
True. Most users don't care, so they will get Flatpaks instead of RPMs.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:02 a.m.
On 30/06/2022 16:44, Michael Catanzaro wrote:
You actually linked straight to the answer. Matthew's response
there is
not some passing speculation; that's the real answer based on discussion
with Fedora Legal.
This is not a real answer. These are double standards.
RPM Fusion is a third-party repository too which provides software for
various Linux distributions: Fedora Linux, Red Hat Enterprise Linux,
Rocky Linux and Alma Linux.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:09 a.m.
On Thu, Jun 30 2022 at 01:54:16 PM +0200, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
Flathub is already preloaded and enabled by default,
Actually it's NOT enabled by default, and we do not propose to change
that. To get Flathub, users must either:
* Press the Enable Third-Party Repositories button on the Third-Party
Repositories page in gnome-initial-setup, or
* Flip one or more switches at the bottom of the Software Repositories
dialog in GNOME Software
The goal is to make it easy for users to find third-party software if
they choose to enable it, but by default stay limited to only open
source software provided by Fedora.
Michael
10:11 a.m.
On Thu, Jun 30 2022 at 02:20:58 PM +0200, Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
That would make a lot of sense indeed (though the default would still
need
to be agreed on). But unfortunately, asking for any kind of user
preference
to be added to a GNOME application is usually a lost cause. GNOME has
a
strict "take it or leave it" policy.
I actually agree that it makes sense to have a preference for this. We
discussed it in the past but gave up because it required effort. The
current Software Sources page is not designed to allow you to reorder
sources in arbitrary ways. It would be easy to expose a switch for the
current "prefer flatpak vs. prefer RPM setting," but that might not be
powerful enough for what users actually want, e.g. it doesn't allow you
to prefer Fedora flatpak > Fedora RPM > Flathub, or Flathub > Fedora
RPM > Fedora Flatpak. I think this is probably a "help welcome" area.
Of course, users have the final choice when installing.
Michael
10:23 a.m.
On Thu, Jun 30 2022 at 05:02:35 PM +0200, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
This is not a real answer. These are double standards.
It's not a double standard: Matthew explained precisely why RPM Fusion
is different and riskier than Flathub. I'm sorry it's not the answer
that you wanted to hear, but rest assured it is the actual answer.
I do not expect Fedora Legal will likely come onto a public mailing
list to debate liability with you. Hopefully it should be obvious why
that's not a good idea. There's nothing more I can do except link you
back to Matthew's post. Sorry.
Michael
10:31 a.m.
On 30/06/2022 17:23, Michael Catanzaro wrote:
I do not expect Fedora Legal will likely come onto a public mailing
list to debate liability with you. Hopefully it should be obvious why that's not a
good idea. There's nothing more I can do except link you back to Matthew's post.
Sorry.
These are double standards. I don't why they hate RPM Fusion.
Fedora is a public, community-driven distribution, so they must post an
official response to our request.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:47 a.m.
On Thu, Jun 30, 2022 at 3:33 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 30/06/2022 17:23, Michael Catanzaro wrote:
> I do not expect Fedora Legal will likely come onto a public mailing list to debate
liability with you. Hopefully it should be obvious why that's not a good idea.
There's nothing more I can do except link you back to Matthew's post. Sorry.
These are double standards. I don't why they hate RPM Fusion.
Fedora is a public, community-driven distribution, so they must post an
official response to our request.
No, they do not, really. Community driven does
not (never has) meant that the community has
the final decision on everything.
If you do not understand this, talk to *your*
lawyer (only your lawyer is responsible to
you) and have them explain the details
and distinctions and reasonings to you.
Whether the RH lawyers recommendations in
this case are good or not, or whether anyone
agrees or not, is, ultimately, not really relevant.
Gary
11:08 a.m.
On 30/06/2022 17:47, Gary Buhrmaster wrote:
If you do not understand this, talk to*your*
lawyer (only your lawyer is responsible to
you) and have them explain the details
and distinctions and reasonings to you.
Each court publishes the reasoning part of the decision.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:17 a.m.
On 6/30/22 11:08, Vitaly Zaitsev via devel wrote:
On 30/06/2022 17:47, Gary Buhrmaster wrote:
> If you do not understand this, talk to*your*
> lawyer (only your lawyer is responsible to
> you) and have them explain the details
> and distinctions and reasonings to you.
Each court publishes the reasoning part of the decision.
This is not a court. It is a group of attorneys providing advice to
their client (which happens to be their employer).
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
2:20 p.m.
The Flathub remote is available to users who opt-in to enabling
third-party software repositories in either GNOME Initial Setup or
GNOME Software.
A lot of flatpaks in Flathub have debatable quality, and are closed source. If we could
wait until flathub separates open-source and proprietary repos, the open-source one could
be unfiltered, and the proprietary one could have a blacklist for very bad packages. I
think it would be better if there could be some sort of warning in GNOME software, so
maintainers could mark certain packages as unsafe or low-quality.
2:25 p.m.
and the proprietary one could have a blacklist for very bad packages.
The ability remains to filter if there is a package that is considered bad
or malicous. The default is just changed to an allow list. Secondly if
there is a malicious package, it will probably be faster to contact flathub
and have them take action that make a downstream update to block it.
6:37 a.m.
On Wed, Jun 29, 2022 at 8:42 PM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
> Flathub should only be preferred when there is no Fedora
Flatpak
available.
I don't see it in the proposal.
I see:
"GNOME Software will prefer Fedora flatpaks over Flathub flatpaks"
What is *not* in the proposal and should be added is a clarification
whether Fedora RPMs or Flathub flatpaks take precedence, when both exist
(and a Fedora flatpak doesn't). My preference would be:
Fedora flatpak > Fedora RPM > Flathub
or
Fedora RPM > Fedora flatpak > Flathub
If this is the case, I believe this Change is a great benefit to Fedora.
I'd be worried if we prioritized third-party software over our own builds.
Yes, the security is better with flatpak over rpm, but there are also other
aspects. Like having things under our own control, or having a pretty good
pre-release testing processes (updates-testing, bodhi, karma) compared to
flathub.
On Thu, Jun 30, 2022 at 4:50 PM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
I would prefer a non-sandboxed app instead of a third-party DEB
repack.
And nobody is taking that option away from you ;-)
You've made your preference known. Repeating it numerous times doesn't
contribute to a pleasant discussion.
7:02 a.m.
On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote:
Regardless, Fedora will still be RPM-based no matter what. ;) Even if
our future is OS images composed of RPMs plus Flatpaks composed by
RPMs, it's still based on RPMs.
I don't think so. I think RPM is a tool, a technique that can be used where it makes
sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we
ship a bit of content that comes directly from the
https://github.com/coreos/fedora-coreos-config git repository without having been
pointlessly put into an RPM first.
Building an intermediate RPM for content that is *only* intended to be run as a container
is just awkward and strange.
7:30 a.m.
On 7/1/22 8:02 AM, Colin Walters wrote:
On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote:
>
> Regardless, Fedora will still be RPM-based no matter what. ;) Even if
> our future is OS images composed of RPMs plus Flatpaks composed by
> RPMs, it's still based on RPMs.
I don't think so. I think RPM is a tool, a technique that can be used where it makes
sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we
ship a bit of content that comes directly from the
https://github.com/coreos/fedora-coreos-config git repository without gavina been
pointlessly put into an RPM first.
It removes a step so it makes it easier, but at the same time remove the
existence of a copy of the source code (SRPM) in parallel with the binaries.
There is a reason all Fedora RPMs sources are stored on Fedora
infrastructure instead of automatic downloads from source repositories.
Imagine an entire Fedora built that way and think about the
reproducibility of that build. Maybe another process could replace it,
but going directly to source repositories is a step backwards.
Building an intermediate RPM for content that is *only* intended to be run as a container
is just awkward and strange.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
8:18 a.m.
On Fri, Jul 1 2022 at 01:37:01 PM +0200, Kamil Paral
<kparal(a)redhat.com> wrote:
What is *not* in the proposal and should be added is a clarification
whether Fedora RPMs or Flathub flatpaks take precedence, when both
exist (and a Fedora flatpak doesn't). My preference would be:
Flatpaks already take precedence over RPMs, and there are no plans to
change this for the reasons I mentioned in my previous mail regarding
sandboxing, which is more important than other considerations.
As mentioned previously, GNOME Software can be configured to prefer
RPMs over Flatpaks, but it cannot currently be configured to allow
arbitrary orderings: that would require additional design and
development work. Users can always have the final say if they wish to
explicitly select the installation source when installing the app.
Michael
1:21 p.m.
On Thu, Jun 30, 2022 at 10:11:43AM -0500, Michael Catanzaro wrote:
We discussed it in the past but gave up because it required effort.
The current Software Sources page is not designed to allow you to
reorder sources in arbitrary ways. It would be easy to expose a
switch for the current "prefer flatpak vs. prefer RPM setting," but
that might not be powerful enough for what users actually want, e.g.
it doesn't allow you to prefer Fedora flatpak > Fedora RPM >
Flathub, or Flathub > Fedora RPM > Fedora Flatpak. I think this is
probably a "help welcome" area.
The thing I'd like to see, but which I don't even have any good ideas for
myself: *after* installation, making it easy to know where running
applications come from and where to get help or report problems -- ideally
separately for the app itself and for packaging/distribution -- all without
being obnoxiously in your face during normal operation.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:32 p.m.
On Fri, Jul 01, 2022 at 08:02:35AM -0400, Colin Walters wrote:
I don't think so. I think RPM is a tool, a technique that can be
used
where it makes sense. It is not and should not be the center of the
universe. Today in Fedora CoreOS we ship a bit of content that comes
directly from the https://github.com/coreos/fedora-coreos-config git
repository without having been pointlessly put into an RPM first.
Building an intermediate RPM for content that is *only* intended to be run
as a container is just awkward and strange.
I agree. RPM makes sense at for the things it solves well, but we should
figure out how we can provide the same (or more) value in other ways too. I
know this is a blast from the past, but this was a central idea from my talk
at Flock in 2013 (https://mattdm.org/fedora/2013next/) and I still believe
we need to get there.
I'd love to see a way to generate Flatpaks directly from our build system
without an intermediate step. Part of the justification for the current
system is an early estimate that 95% of desktop apps already packaged could
have flatpak versions without any additional work... that turned out to be not
so in practice. It was a good experiment, but we shouldn't feel stuck to it.
(Also, it was expecting a lot more improvements in modularity infrastructure
which never got resourced for reasons not worth rehashing.)
Same goes for some container content, too. Thinking about java stuff there
in particular, as well as various web-apps we package.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:36 p.m.
On Fri, Jul 01, 2022 at 08:30:33AM -0400, Robert Marcano via devel wrote:
It removes a step so it makes it easier, but at the same time remove
the existence of a copy of the source code (SRPM) in parallel with
the binaries.
We absolutely need that, but source RPMs are not the only (or best!) way to
do that.
There is a reason all Fedora RPMs sources are stored on Fedora
infrastructure instead of automatic downloads from source
repositories. Imagine an entire Fedora built that way and think
about the reproducibility of that build. Maybe another process could
replace it, but going directly to source repositories is a step
backwards.
If we had all of the source exploded into source repositories under our
control, and built from that, we probably could get _more_ reproducibility.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:45 p.m.
Too complicated for the average user. It should be visible when you
click the "Install" button.
I agree. There is currently a proposal to display the sources dropdown below the
"install". It looks way better and more discoverable.
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1754
2:45 p.m.
Too complicated for the average user. It should be visible when you
click the "Install" button.
I agree. There is currently a proposal to display the sources dropdown below the
"install". It looks way better and more discoverable.
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1754
4:23 a.m.
On 01/07/2022 20:32, Matthew Miller wrote:
I'd love to see a way to generate Flatpaks directly from our
build system
without an intermediate step.
+1. Flatpaks should be built natively on our trusted infra from standard
Flatpak manifests.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:44 a.m.
Vitaly Zaitsev via devel wrote:
On 01/07/2022 20:32, Matthew Miller wrote:
> I'd love to see a way to generate Flatpaks directly from our build system
> without an intermediate step.
+1. Flatpaks should be built natively on our trusted infra from standard
Flatpak manifests.
While we agree on almost all points, in this case I disagree in so much as I
think Fedora should not be in a business of building Flatpaks at all,
neither from RPMs, nor directly. The Flatpak technology has just too many
drawbacks compared to good old RPMs. And the Fedora Flatpaks project is
essentially unmaintained, or the required fedmod tool would not have been
retired months ago (and not unretired since).
Kevin Kofler
11:25 a.m.
The two articles mentioned above all full of errors and misconceptions about how Flatpak
and Flathub works.
See
https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-t...
2:47 p.m.
Timothée Ravier wrote:
The two articles mentioned above all full of errors and
misconceptions
about how Flatpak and Flathub works.
See
https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-t...
Oh, I know that "response". That response fails to convincingly address any
of the criticism in the "Flatpak is not the Future" article.
Let me just go through the first section, "Size":
Section introduction:
* The response first tries to explain away the problem, trying to tell us
why it is so bad to use host libraries (contrary to the best practices
Fedora has been trying to promote all this time).
* Then it explains that we do not in fact have a 900 MB calculator, but
"only" a 550 MB calculator, as if that were any more acceptable.
Sharing Runtimes:
The response seriously tries to sell us "113 MB out of 498 MB were
deduplicated" (less than ¼) and "388 MB out of 715 MB were deduplicated"
(about half) as a success of deduplication. (That is still a 75% resp. 50%
space waste compared to having just one runtime.)
Storage Usage:
"Only 13.07 GB are used with deduplication", LOL, enough said! Though, if
you insist on percentages, "13.07 GB are used with deduplication" vs.
"36.22
GB without" means that 64% are saved and 36% are still used if you have an
incredible "57 runtimes". (Fewer runtimes also mean less opportunity to
deduplicate.) Still, 57 times 36% is still a factor of more than 20, i.e.,
the proliferation of runtimes means you need 20 times the space for runtimes
that a single shared runtime (as in the RPM world) would need.
"Disk space is cheap!":
* The criticism was that this no longer holds, which seems obvious looking
at current prices. Yet, the response still tries to explain that away by
claiming that "flash storage have higher physical density than hard drives
because of built-in compression and deduplication". But no amount of
compression and deduplication can increase the worst-case size of the disk
that can be relied on, because it only works on data that is compressible
or duplicate.
* The response then proceeds to showing gains on Flatpak data from
partition-level deduplication and compression (which is not actually a
feature of flash storage at all, but of the in-kernel file system). That
there is anything to be gained at all from partition-level deduplication
just shows that Flatpak's own deduplication is nowhere near as effective
as advertised. And partition-level compression is 1. slow and 2. can also
be done just as effectively on software installed from RPMs (so it is not
fair to compare compressed Flatpak installations with uncompressed RPM
installations for size).
Memory Usage, Startup Time:
The response starts with "This is assuming the user has the same
applications installed on the system and as a Flatpak and wants to load
both.", which is a false assertion. In order to share libraries in memory,
the applications need not be the same, they just need to use the same
libraries, e.g., Qt, GTK, etc., and they typically do. So the whole two
response paragraphs that follow are invalid (due to being deduced from this
false premise).
I can take apart the rest when I have more time, but you should get the
idea.
Kevin Kofler
6:57 p.m.
I don't believe the technical details are as significant as the
systemtic change to the boundaries of trusted software maintainers.
Consider this comment, which appears to be the core justification:
Michael Catanzaro wrote:
Flatpaks already take precedence over RPMs, and there are no plans to
change this for the reasons I mentioned in my previous mail regarding
sandboxing, which is more important than other considerations.
A sandboxed trojan application is still capable of damaging the user's
security, even if it can't damage the system's security.
To illustrate the difference, a subverted browser can share all credit
card details seen (user's security compromised), but removing that
software removes the subversion (system security not compromised)
A preference order of
Fedora Flatpak > GNOME Flatpak > Fedora RPM
makes user's security of graphical applications reliant upon a wider
set of trusted software maintainers than
Fedora Flatpak > Fedora RPM > GNOME Flatpak
Essentially, for graphical applications the change makes Fedora trust
and security processes approach the minimum of of Fedora trust and
security processes and GNOME trust and security processes. That's
change to the security stance of the distribution which requires
explicit discussion prior to accepting the change.
-glen
12:26 p.m.
On 6/30/22 10:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is
untrusted" and "Flathub packaging is poor" since proponents of these
arguments conveniently ignore the fact that traditional RPMs are
totally unsandboxed. [...]
Opponents of Flatpak have had seven years since Flatpak launched to
figure out an alternative model to make apps safe using firejail or
bwrap or whatever, but nobody ever seriously did, and at this point
the endgame has arrived with a *commanding* lead in favor of Flatpak.
So it's time to move on.
There are two separate issues: sandboxing and library
duplication/lifecycle management. I agree that sandboxing is desirable,
but I don't think we should give up on the shared libraries, because of
their savings of memory and storage, and because of their better
security profile.
I see how RPM-driven flatpaks can actually mitigate the security
issue--presumably any vulnerability fixes/updates to system libraries
also end up in the rebuilt flatpaks, so they would not rot in place.
Still, the library/runtime duplication bothers me and I hope that there
will be some technical solution to it.
651
days inactive
665
days old
55 comments
26 participants
participants (26)
-
Artur Frenszek-Iwicki -
Colin Walters -
Daniel P. Berrangé -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Gary Buhrmaster -
Glen Turner -
Jarryd Lisher -
Joaquim Nascimento -
Kamil Paral -
Kevin Kofler -
Kevin P. Fleming -
Marc Pervaz Boocha -
Matthew Miller -
Michael Catanzaro -
Michael J Gruber -
Naheem Zaffar -
Neal Gompa -
Przemek Klosowski -
Richard Hughes -
Robert Marcano -
Sharpened Blade -
Timothée Ravier -
Vipul Siddharth -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek