Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> Jaroslav Reznik wrote:
> > = System Wide Change: Graphical Applications as Flatpaks =
> > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> > 
> > Change owner(s):
> > * Owen Taylor 
> 
> 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?
> 
> * 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.

Why do we care about FHS compliance inside a Flatpak? And why would it be
slower to release security fixes?
 
> I strongly oppose this change.

You forgot the positive changes such as:
- sandboxing
- dogfooding and testing for the sandboxing technologies
- make it possible to create Flatpaks quicker for some more complicated apps
- developers not having to learn GPG to sign their releases
- more efficient update tracking than RPM (eg. no need to download 20 megs of
  metadata to know there's nothing to update)

There's plenty more depending on which part of the chain you'd be in.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Martin Kolman]

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 
> 
> 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?
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
> 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. 
I see quite a few:
- 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
security


> And the 
> portability argument is moot when we are talking about delivering
> Fedora 
> 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
now.

> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Nico Kadel-Garcia]

On Sun, Jul 9, 2017 at 6:46 PM, Kevin Kofler  wrote:
> Jaroslav Reznik wrote:
>> = System Wide Change: Graphical Applications as Flatpaks =
>> https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
>>
>> Change owner(s):
>> * Owen Taylor 
>
> This change is leaving several questions unanswered:

But... it's shiny! And new! And distinct from all other packaging
systems, so it won't have *any* of the problems any or all of them
have shown! And if there's a conflict, overwrite, or embedded
incompatible library or conflicting dependency, it will be a Simple
Matter Of Programming. And it could not possibly run into any of those
more difficult already documented and partially addressed conflicts
because, hey, it's *new* and people will stop using the other tools
immediately due to its obvious superiority!

Sorry, but I've been seeing these kinds of issues for a long time.
pkg, apt, rpm, VM images, docker, chroot cages, encap, pyvenv, and
associated build tools such as autoconf, CPAN, pip, ant, maven, and
gradle.  I still see a lot of inevitable and unavoidable conflicts
between system libraries published with RPM and flatpack bundled
graphical packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Kevin Kofler]

Jaroslav Reznik wrote:
> = System Wide Change: Graphical Applications as Flatpaks =
> https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> 
> Change owner(s):
> * Owen Taylor 

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?

* 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 strongly oppose this change.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Graphical Applications as Flatpaks

[Jaroslav Reznik]

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor 

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.

== Detailed Description ==

See Workstation/Flatpaks [1] for the full development plan.

The goal of this change is make Flatpaks available as a distribution
mechanism for software packaged in Fedora.

Multiple Flatpaks on the system can share a runtime of common
libraries. There will be a single Fedora runtime maintained on the
same schedule as the Platform module for Fedora. It will be be defined
as a module that includes libraries that are commonly used for
graphical applications. Some of these will inherit from the Platform
module.

Applications then bundle the code for the application itself and for
additional libraries they depend on beyond the base runtime. Each
application has its own module in which the relevant RPMs are rebuilt
with a special RPM macros (in the flatpak-rpm-macros package) to
relocate the application and bundled libraries into the /app prefix.
(This is necessary, because inside an executing Flatpak, the
application is mounted at /app, and the runtime at /usr)

The packages are then composed into Flatpaks by the layered image
service, sharing as much of the workflow and code as possible with
containers. While the native delivery mechanism for Flatpaks is as an
ostree repository, they can also be distributed as OCI images, and our
goal is to use this format during the build process, and to distribute
them to users via registry.fedoraproject.com.

Automation of rebuilds and integration with Bodhi will also be needed
to make sure that security and bug-fix updates to packages end up
being distributed to users. This part is least specified at the
current time, and full automation may not be achievable for Fedora 27.
If the above plan is followed, most of this work is shared with work
needed for modularity in general and for server-side containers.

== Scope ==
* Proposal owners: (f27)
** Create and maintain a flatpak-runtime module
** Provide tools for application authors to use to create module
descriptions for their flatpaks
** Provide patches for the container build pipeline (atomic reactor
and friends) to build flatpaks as well as containers
** Create some way to get summary information for all flatpaks on
registry.fedoraproject.org; this might be a patch to the codebase, a
look-aside file, or a separate service.
** Modify flatpak and gnome-software so that flatpaks can be installed
from registry.fedoraproject.org.

* Proposal owners: (f28)
** Provide a "SDK" profile of the flatpak-runtime module to create a
Flatpak SDK for third-party non-RPM builds against the SDK using
flatpak-builder

* Other developers: (f27)
** Provide exports of built modules as repositories (the "On Demand
Compose Service")
** Provide some reasonably self-service way for packagers to create
modules without a lot of overhead. (Does it make sense to allow
''application modules'' where when a package corresponds one-to-one to
a module to allow the modulemd to live in dist-git next to the spec
file?)
** Allow Fedora packagers to submit module builds
** Allow uploading OCI images to registry.fedoraproject.org Upstream
pull request [2]
** Make sure that Bodhi updates can be submitted for Flatpaks/OCI
Images in the same way as for Docker containers (no significant code
changes are expected beyond the current work to enable multiple types
of Bodhi updates.)

* Other developers: (f28)
** Create a unified workflow for package and container/flatpak updates
(detailed plan to be developed, something like:)
*** updates submitted to bodhi for a package should trigger automatic
module and container/flatpak builds
*** Pushing a package to stable should push the updated flatpaks/containers
*** the Bodhi user interface should show modules/containers that
include a package and their status

* Release engineering: [3] (a check of an impact with Release
Engineering is needed)
** List of deliverables: Most likely, runtime and applications would
not be part of the deliverables list. However, we will need to
consider the quality of the runtime and applications as part of the
overall quality of release - if some common application did not run on
upgrade that would seriously affect users. This should, as much as
possible, be addressed through continuous automated testing.

* Policies and guidelines: The people working on this change will need
to work closely in the development of module guidelines, and make sure
that Flatpak specifics are documented as well (for example,
documenting the creation of a 'flatpak.json' with permissions and
other metadata for the Flatpak). It's possible some changes will be
needed to the packaging guidelines to make sure that all relevant
packages relocate to /app properly, but it's 

F27 System Wide Change: Graphical Applications as Flatpaks

[Jaroslav Reznik]

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor 

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.

== Detailed Description ==

See Workstation/Flatpaks [1] for the full development plan.

The goal of this change is make Flatpaks available as a distribution
mechanism for software packaged in Fedora.

Multiple Flatpaks on the system can share a runtime of common
libraries. There will be a single Fedora runtime maintained on the
same schedule as the Platform module for Fedora. It will be be defined
as a module that includes libraries that are commonly used for
graphical applications. Some of these will inherit from the Platform
module.

Applications then bundle the code for the application itself and for
additional libraries they depend on beyond the base runtime. Each
application has its own module in which the relevant RPMs are rebuilt
with a special RPM macros (in the flatpak-rpm-macros package) to
relocate the application and bundled libraries into the /app prefix.
(This is necessary, because inside an executing Flatpak, the
application is mounted at /app, and the runtime at /usr)

The packages are then composed into Flatpaks by the layered image
service, sharing as much of the workflow and code as possible with
containers. While the native delivery mechanism for Flatpaks is as an
ostree repository, they can also be distributed as OCI images, and our
goal is to use this format during the build process, and to distribute
them to users via registry.fedoraproject.com.

Automation of rebuilds and integration with Bodhi will also be needed
to make sure that security and bug-fix updates to packages end up
being distributed to users. This part is least specified at the
current time, and full automation may not be achievable for Fedora 27.
If the above plan is followed, most of this work is shared with work
needed for modularity in general and for server-side containers.

== Scope ==
* Proposal owners: (f27)
** Create and maintain a flatpak-runtime module
** Provide tools for application authors to use to create module
descriptions for their flatpaks
** Provide patches for the container build pipeline (atomic reactor
and friends) to build flatpaks as well as containers
** Create some way to get summary information for all flatpaks on
registry.fedoraproject.org; this might be a patch to the codebase, a
look-aside file, or a separate service.
** Modify flatpak and gnome-software so that flatpaks can be installed
from registry.fedoraproject.org.

* Proposal owners: (f28)
** Provide a "SDK" profile of the flatpak-runtime module to create a
Flatpak SDK for third-party non-RPM builds against the SDK using
flatpak-builder

* Other developers: (f27)
** Provide exports of built modules as repositories (the "On Demand
Compose Service")
** Provide some reasonably self-service way for packagers to create
modules without a lot of overhead. (Does it make sense to allow
''application modules'' where when a package corresponds one-to-one to
a module to allow the modulemd to live in dist-git next to the spec
file?)
** Allow Fedora packagers to submit module builds
** Allow uploading OCI images to registry.fedoraproject.org Upstream
pull request [2]
** Make sure that Bodhi updates can be submitted for Flatpaks/OCI
Images in the same way as for Docker containers (no significant code
changes are expected beyond the current work to enable multiple types
of Bodhi updates.)

* Other developers: (f28)
** Create a unified workflow for package and container/flatpak updates
(detailed plan to be developed, something like:)
*** updates submitted to bodhi for a package should trigger automatic
module and container/flatpak builds
*** Pushing a package to stable should push the updated flatpaks/containers
*** the Bodhi user interface should show modules/containers that
include a package and their status

* Release engineering: [3] (a check of an impact with Release
Engineering is needed)
** List of deliverables: Most likely, runtime and applications would
not be part of the deliverables list. However, we will need to
consider the quality of the runtime and applications as part of the
overall quality of release - if some common application did not run on
upgrade that would seriously affect users. This should, as much as
possible, be addressed through continuous automated testing.

* Policies and guidelines: The people working on this change will need
to work closely in the development of module guidelines, and make sure
that Flatpak specifics are documented as well (for example,
documenting the creation of a 'flatpak.json' with permissions and
other metadata for the Flatpak). It's possible some changes will be
needed to the packaging guidelines to make sure that all relevant
packages relocate to /app properly, but it's