Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
Hi, I think the response article has one paragraph which is important to this discussion:"Since Fedora Flatpaks converts RPMs from the Fedora repositories to Flatpak applications, it is much easier to trust and audit from a Fedora Project developer and maintainer perspective. Furthermore, these RPMs already comply with all Fedora Project’s conducts and standards. They’re all built inside the Fedora Project’s infrastructure and based on RPMs that are maintained by Fedora Project maintainers. Flathub, on the other hand, is independent and unaffiliated with the Fedora Project. This also makes auditing harder for the Fedora Project maintainers."Which highlights the importance of prioritising Fedora packages over Flathub packages, regardless of whether they are RPMs or Flatpaks. --Jarryd 18:27, 05 July 2022, "Timothée Ravier" :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-the-future.html___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.orgDo not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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-the-future.html 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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-the-future.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Fri, Jul 1 2022 at 01:37:01 PM +0200, Kamil Paral 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Wed, Jun 29, 2022 at 8:42 PM Vitaly Zaitsev via devel < devel@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@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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30, 2022 at 3:33 PM Vitaly Zaitsev via devel 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30 2022 at 05:02:35 PM +0200, Vitaly Zaitsev via devel 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30 2022 at 02:20:58 PM +0200, Kevin Kofler via devel 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30 2022 at 01:54:16 PM +0200, Vitaly Zaitsev via devel 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30 2022 at 12:16:09 PM +0200, Vitaly Zaitsev via devel wrote: They don't want to answer why they can't preload RPM Fusion: https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/TCULL55CJGEAYKK5SLHNHZ4BGEUWM3KL/ 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> I'd imagine a single slider (or drop-down menu or whatever) Once you open the app screen details, there is a drop-down for this, integrated into the top bar, next to the app name. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30, 2022 at 8:11 AM Zbigniew Jędrzejewski-Szmek 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, 30 Jun 2022 at 10:41, Dominik 'Rathann' Mierzejewski 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
>
> 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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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/le...@lists.fedoraproject.org/thread/TCULL55CJGEAYKK5SLHNHZ4BGEUWM3KL/
LWN news article: https://lwn.net/Articles/897793/
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 > 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/0709681441daf6b182a062d24c543174346b36d8/data/org.gnome.software.gschema.xml#L137 > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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=code > - https://github.com/search?q=org%3Aflathub+filesystem%3Dhost=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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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=code > - > https://github.com/search?q=org%3Aflathub+filesystem%3Dhost=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 (vit...@easycoding.org) > Thanks & Regards, Marc Pervaz Boocha ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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=code - https://github.com/search?q=org%3Aflathub+filesystem%3Dhost=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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel 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/0709681441daf6b182a062d24c543174346b36d8/data/org.gnome.software.gschema.xml#L137 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
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.Signal.yaml#L62-L65
-
https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98-L103
-
https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L143-L145
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=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost=code
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
