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(a)redhat.com>
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org