That is a lot of different things mashed into one here, and while I can not even begin to understand how you can bash our commitment to Free Software and at the same time be an argent backer of Shuttleworths Snappy is beyond me, but I am sure is somehow makes sense to you. Also I don't think it is true in any way or form that the Working Group is discouraging people from making RPMS, in fact I have personally talked to a lot of different companies and people over the last year encouraging to them to make RPMS. And Bastien Nocera who was the one on this thread encouraging making a Flatpak is not a Working Group member, in fact he is just a community member doing what he has every right to do, which is to advocate the solution he thinks is best for the problem at hand. And you of course have every right to advocate for a different approach, but I don't see why you think slagging the Workstation Working Group somehow is the correct response. The proposals you misrepresent so wonderfully was a general issue of how do we deal with the same application being available in multiple formats, which is not even limited to RPM and Flatpak. Offering users 10 versions of the same application at the same version number with the only difference being the package technology used is confusing and stupid. And we need to have a policy for dealing with it and dealing with the fact that the recommended packaged version of an application might change their package format over time. This could go both ways, but of course since we have mostly RPMS these days the likelyhood is that at least in the beginning the most common case will mostly be away from RPMS. And to be clear the working group isn't spending time trying to figure out how we can offer the Gimp as a Flatpak for example, just because it is not a very interesting problem to solve, since we already have the Gimp as an RPM. Instead we are focusing on using Flatpaks as a method for bringing new applications to the Fedora ecosystem. Christian ----- Original Message ----- > From: "Neal Gompa" <ngompa13@xxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, December 14, 2016 10:52:37 AM > Subject: Re: GSequencer upstream wants to package for fedora > > On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller > <cschalle@xxxxxxxxxx> wrote: > > That is not 100% correct. You can make a non-sandboxed Flatpak and > > it would work just as well as an RPM in terms of hardware access. > > Enabling sandboxing however would need some thought and development > > for a lot of such applications, but we are slowly but surely working > > on it through things like the PulseAudio and Pinos work that Wim Taymans > > is doing, and through the work that Alex Larsson has been doing with > > OpenGL. > > There's also the fact that the runtimes provided also crash on most of > my computers, but hey, that's just a small thing, right? > > Speaking with my Fedora and Mageia hats, there's nothing that stops > ANYONE from making portable RPMs (I've done it fairly easily myself). > Flatpak, AppImage, Snappy, etc. do not provide any material advantages > without some sandboxing. In fact, they just make applications more > bloated for little to no benefit at that point. > > IMO, the only reason that we're starting to see this is because we're > increasingly giving up on Free Software (note capital letters). These > systems primarily benefit nonfree/proprietary software developers. > > Speaking with my Snappy hat on, the concept of making it possible for > people to make applications that work everywhere and anywhere is a > very nice dream. But it's important to realize that the integration > work has to happen somewhere. Flatpak is moving too slowly in this > regard, and while Snappy has this functionality in spades, it requires > much deeper integration into the distribution than Flatpak does. The > main things keeping snaps from being a first class citizen on Fedora > are the inability to produce snaps based on a Fedora base and Fedora > packages (that's being worked on) and the lack of SELinux integration > (also being worked on). > > I've personally been working on these things for the Snappy system, > but the Flatpak guys seem to be doing *nothing* about it. I'm very > disappointed in the progress of the Flatpak system. > > To date, it is still not possible to install Flatpaks through Plasma > Discover like it is through GNOME Software. It is not possible to > build Flatpaks from RPMs in such a manner where Fedora-based runtimes > could power software. (Hint: both GNOME and KDE app stores support > Snappy!) There is no evangelism from the people working on Flatpak to > demonstrate the technology and drive any useful interest. The > sandboxing in Flatpak is so restrictive that it's not possible to use > it for a very wide variety of common applications. Even applications > like VLC are not properly functional in Flatpak, whereas they are as a > Snap. > > Speaking without any of my hats on, Flatpak and Snap both offer a > different way to distribution various classes of applications. But > we're still at the point where they are not overly useful. And I'm > getting increasingly upset with the Fedora Workstation WG over their > attitude of discouraging people from contributing software to Fedora > as RPMs. The proposals I've seen from them about automatically > removing RPMs in favor of Flatpaks or hiding them so that they are not > obvious or easy to install are horrifyingly bad. > > I'm increasingly worried that the Workstation WG has lost sight of our > founding principles as a project, and are forgetting that our goal is > to make the best Free system out there, to show that Free Software is > the best model for producing a high-quality system. > > What has happened to Fedora? What has happened to us? > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
