On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote: > Jaroslav Reznik wrote: > > = System Wide Change: Graphical Applications as Flatpaks = > > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl > > atpaks > > > > Change owner(s): > > * Owen Taylor <otaylor@xxxxxxxxxx> > > This change is leaving several questions unanswered: > > * As I understand it, those Flatpaks are going to be built from RPMs. > Is the intent to ship both the original RPMs and the Flatpak or only > the Flatpak (or is this going to depend on the individual package)? > And if the former, are the shipped RPMs going to be the FHS-compliant > version or the one relocated into Flatpak's proprietary prefix? The rebuilt RPMs are really only interesting within Flatpaks - they will be available for download from Koji, but there would be no reason for a user to do so. As for standard application RPMs, it's really going to be something we figure out over time. My vision is something like: F27: packagers are *able* to create Flatpaks of their application. They must also maintain standard RPMs. F28: packagers (of graphical applications) are *encouraged* to create Flatpaks of their applications along side standard RPM packaging. They *may* drop the standard RPM packaging if there is good reason to. F29: packagers (of graphical applications) must create Flatpaks of their applications if possible. They *may* keep standard RPM packaging. But this is really highly dependent on how modularity work happens more widely in Fedora. "standard RPM packaging" assumes we still have a F<N> tag in Koji where everything is built together with common coordinated dependencies. The Change proposal, in any case is really only about enabling this as an something that packagers may opt into if they want to. > * What is the advantage of shipping Fedora distribution packages > to Fedora users as Flatpaks? I see only drawbacks compared to RPM, > because everything not included in the base runtime must be bundled, > so we have all the usual issues of bundled libraries: larger > downloads, more disk consumption, more RAM consumption (shared system > libraries are also shared in RAM), slower and less efficient delivery > of security fixes, FHS noncompliance, etc. And the portability > argument is moot when we are talking about delivering Fedora > software to Fedora users. I think this is addressed fairly well in the change proposal (I forgot to mention sandboxing, so I just edited the proposal to include another bullet point for that under "Benefit to Fedora". > I strongly oppose this change. I appreciate you asking questions anyways! Owen > Kevin Kofler > _______________________________________________ > 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
