On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
Jaroslav Reznik wrote:
> = System Wide Change: Graphical Applications as Flatpaks =
> 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.
intent to ship both the original RPMs and the Flatpak or only the
(or is this going to depend on the individual package)? And if the
are the shipped RPMs going to be the FHS-compliant version or the
relocated into Flatpak's proprietary prefix?
I can image Flatpak applications
that are not available in Fedora as
RPMs (or as a RPM in COPR, etc.) that use Fedora RPMs for their
dependencies, possibly bundling the few missing dependencies on top.
* What is the advantage of shipping Fedora distribution packages to
users as Flatpaks? I see only drawbacks compared to RPM, because
not included in the base runtime must be bundled, so we have all the
issues of bundled libraries: larger downloads, more disk consumption,
RAM consumption (shared system libraries are also shared in RAM),
less efficient delivery of security fixes, FHS noncompliance, etc.
I see quite a
- thanks to how runtimes work it should be possibly to install Flatpack
applications to older/newer Fedora releases than the one where the
application originates from
- easy to use development versions without breaking the RPM installed
version of an application
- I guess it should be possibly to install multiple version of an
application in parallel (for testing, etc.)
- better sandboxing than RPM installed apps, possibly improving
portability argument is moot when we are talking about delivering
software to Fedora users.
I would still expect the resulting Flatpacks to work even
on let's say
Ubuntu given how (AFAIK) the Flatpak runtimes work. So I don't think
this argument is moot.
I strongly oppose this change.
As I understand the change this is just an
additional mechanism for
graphical application delivery - no one is taking away the normal RPM
based mechanism. So I don't think it makes sense to oppose an effort
that is just providing an additional mechanism to what we already have
> Kevin Kofler
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org