10:05 a.m.
= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
Change owner(s):
* Owen Taylor <otaylor(a)redhat.com>
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 expected that most
packages that follow the current packaging guidelines will work
correctly.
* Trademark approval: N/A (not needed for this Change)
[1] https://fedoraproject.org/wiki/Workstation/Flatpaks
[2] https://github.com/docker/distribution/pull/2076
[3] https://pagure.io/releng/issue/6876
Thanks,
Jaroslav
5:46 p.m.
Jaroslav Reznik wrote:
= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/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. 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
8:49 p.m.
On Sun, Jul 9, 2017 at 6:46 PM, Kevin Kofler <kevin.kofler(a)chello.at> 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 <otaylor(a)redhat.com>
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.
5 a.m.
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?
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
5:05 a.m.
----- 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 <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?
* 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.
11:51 a.m.
On 07/06/2017 11:05 AM, Jaroslav Reznik wrote:
= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
Change owner(s):
* Owen Taylor<otaylor(a)redhat.com>
This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.
I do recognize that the containerization trend solves enough problems to
be an attractive and perhaps inevitable development. My concern is more
from the Fedora governance side: given that Fedora is historically a
coherent RPM-based distribution, the containerization has an opportunity
cost, in at least two ways:
- it could distract already overworked package maintainers from properly
coordinating ("I don't have time to deal with those dependencies, I will
just wrap the stuff I need into a flatpack and have a beer and a movie")
- it could distract users from demanding a well-put-together base ("I
don't have time to chase and report this bug; I will just install that
flatpack").
I do appreciate that if there are technical solutions to the downsides
of containerization (security lifecycle, combinatorial divergence,
etc.), it may end up replacing the package-based distribution model, but
I think it's too early to declare such change. So, from the point of
view of Fedora's available resources, are the benefits to Fedora
compelling enough to justify this project?
Please note that I am not arguing against this idea, just pointing out
that the Fedora community should think through its broader consequences.
1:29 p.m.
Thanks for the thoughtful comment!
The ability for different applications to bundle different library versions is only one of
the benefits that Flatpak's bring - other benefits like sandboxing, the ability to try
out applications from newer and older versions of Fedora, and the ability to do robust
upgrades without disturbing running applications would apply even if Fedora was keeping
the idea of a single big package set.
And some of my early attempts to figure out Flaptak building actually assumed the big
consistent package set.
But because Fedora is moving toward a modular world, the current plan for Flatpak support
tries to work within that framework rather than the older big-package-set idea. And in
that world, as long as the libpng maintainer is maintaining a libpng-1.6 branch in
dist-git, you'll be able to use that for your application even if other applications
have moved to libpng-1.8.
[ Hypthetical example, libpng should be in the runtime, not bundled with the app, because
it is security critical. But the same applies to most easy examples. ]
But it should also be noted that modularity does not in any way abandon the idea of the
collective maintenance of packages. There is still a single dist-git repository for each
library or application, even if it is built into multiple different modules. And those
dist-git repositories have to have clear lifetimes and interrelationships - a maintained
branch of libpng can't depend on a branch of libz that is no longer maintained.
In some places (for example, security updates) I don't think we've fully figured
out all the implications of this move to dist-git as the center of information, but
we'll have to make it work for modularity to work.
One thing that the Flatpak work does is give some good concrete examples of modularity in
practice!
Owen
----- Original Message -----
> On 07/06/2017 11:05 AM, Jaroslav Reznik wrote:
>
>
>
> = System Wide Change: Graphical Applications as Flatpaks =
> https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> Change owner(s):
> * Owen Taylor <otaylor(a)redhat.com> This change is to enable package
> maintainers to build Flatpaks of
> their applications and make those Flatpaks available for installation.
>
>
> I do recognize that the containerization trend solves enough problems to be
> an attractive and perhaps inevitable development. My concern is more from
> the Fedora governance side: given that Fedora is historically a coherent
> RPM-based distribution, the containerization has an opportunity cost, in at
> least two ways:
>
> - it could distract already overworked package maintainers from properly
> coordinating ("I don't have time to deal with those dependencies, I will
> just wrap the stuff I need into a flatpack and have a beer and a movie")
>
>
> - it could distract users from demanding a well-put-together base ("I don't
> have time to chase and report this bug; I will just install that flatpack").
>
> I do appreciate that if there are technical solutions to the downsides of
> containerization (security lifecycle, combinatorial divergence, etc.), it
> may end up replacing the package-based distribution model, but I think it's
> too early to declare such change. So, from the point of view of Fedora's
> available resources, are the benefits to Fedora compelling enough to justify
> this project?
>
>
> Please note that I am not arguing against this idea, just pointing out that
> the Fedora community should think through its broader consequences.
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
2:31 p.m.
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
7:45 p.m.
Bastien Nocera wrote:
Why do we care about FHS compliance inside a Flatpak?
Because the proprietary directory layout means the applications (and the
libraries!) have to be specially built for it, and in the worst case,
require code and/or build system changes to deal with it.
And why would it be slower to release security fixes?
With system libraries, if there is a security issue in a library, the
library is updated by upstream, packaged, and delivered directly to the
user.
With bundled libraries, if there is a security issue in a library, the
library is also updated by the library's upstream, but then the bundle needs
to be rebuilt with the new library and the whole bundle has to be delivered
to the user. The extra step of rebuilding the bundle (which typically
involves an additional maintainer) is what takes extra time.
In the discussed approach where the Flatpak is composed from RPMs, the
library is updated by upstream, packaged, the Flatpak is rebuilt with the
new library, and that is delivered to the user. So the extra step happens
between the packaging of the library and the delivery to the user.
In scenarios where Flatpaks are shipped by upstream, they will also have to
rebuild the library in some way, or wait for their distribution to update
the package. But in addition, most upstreams will probably just do
cumulative updates of the libraries when they do a new release of their own
code (if at all!) and not do timely security updates at all.
There is also the efficiency issue of having to update the whole bundle,
which will encourage cumulative updates and discourage quick security
updates. If the bundle is updated for every library security update, there
will be a lot to download. People are already complaining about the size of
Fedora updates as it stands, without having to update dozens of huge bundles
whenever a commonly used library is updated.
And it is also not possible to just stuff all libraries into the runtime to
avoid this issue, because then the runtime becomes a huge pile of libraries
that the user may or may not actually use, and updating the runtime (which
would have to be done the more frequently the more libraries it contains)
becomes very inefficient due to its size.
You forgot the positive changes such as:
- sandboxing
- dogfooding and testing for the sandboxing technologies
There ought to be better ways to sandbox applications than to turn them into
what is essentially a full container (i.e., almost a full VM, only minus the
kernel), bundling all the libraries. The split into an application and a
runtime that Flatpak does is only a partial workaround.
We really need sandboxing technologies that work with shared system
libraries (also allowing the code segments to be shared in RAM). And in
fact, we already have those technologies:
* Fedora ships and heavily promotes SELinux, which in fact, as far as I
know, is also part of the sandboxing technologies Flatpak uses.
* seccomp also looks very promising. Chromium (and QtWebEngine) is already
using it effectively.
Bundling libraries has many drawbacks, including security-related ones (as I
explained above). (It also wastes download bandwidth, disk space, and RAM.)
To really improve security, we must provide the benefits of sandboxing
without bundling libraries.
- make it possible to create Flatpaks quicker for some more
complicated
apps
That just requires shipping the tools for third parties to use, not using
them to deliver software packaged by Fedora.
- developers not having to learn GPG to sign their releases
That is a very weak argument. It is very straightforward to set up an RPM
signing key, not any harder than writing a specfile. And then you just run
rpmsign --addsign to sign the RPMs.
And in the end, you are just saying that Flatpak does away with a critical
security feature. Relying exclusively on the sandboxing for security is a
very bad idea. Sandbox evasion exploits exist.
- more efficient update tracking than RPM (eg. no need to download 20
megs
of metadata to know there's nothing to update)
But less efficient updating, because you will need to download much more
than 20 megs of bundled libraries. The only reason the metadata is smaller
is because there is almost no dependency information encoded (only a single
dependency on a runtime). But those dependencies are what makes installing
and updating packages so efficient! Flatpak throws away the main competitive
advantage of GNU/Linux!
And it is actually possible to solve the metadata size issue, see the work
on metadata deltas. (There was at least one talk at DevConf on this.)
Kevin Kofler
11:26 p.m.
Hey Kevin,
Thanks for your detailed response. I usually try not to read or write
long mails, but I made an exception this time. :)
On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Bastien Nocera wrote:
> Why do we care about FHS compliance inside a Flatpak?
Because the proprietary directory layout means the applications (and
the
libraries!) have to be specially built for it, and in the worst case,
require code and/or build system changes to deal with it.
Yes, this is true. Sometimes minor changes to applications are required
to adjust paths. And sometimes it can be rather frustrating to debug
such issues when trying to package an app as a Flatpak. (Debugging
Flatpak apps is not easy.) So although we can automate most of the work
of creating the Flatpaks, only a human can make sure they're working
properly and fix problems when they're not.
> And why would it be slower to release security fixes?
With system libraries, if there is a security issue in a library, the
library is updated by upstream, packaged, and delivered directly to
the
user.
With bundled libraries, if there is a security issue in a library, the
library is also updated by the library's upstream, but then the
bundle needs
to be rebuilt with the new library and the whole bundle has to be
delivered
to the user. The extra step of rebuilding the bundle (which typically
involves an additional maintainer) is what takes extra time.
Yes.
In the discussed approach where the Flatpak is composed from RPMs,
the
library is updated by upstream, packaged, the Flatpak is rebuilt with
the
new library, and that is delivered to the user. So the extra step
happens
between the packaging of the library and the delivery to the user.
Maybe. I'm not sure about this. I believe the Flatpaks we're initially
planning to distribute will be composed from *Fedora* RPMs... not
upstream Flatpaks, at least not at first. So it should be possible to
build Fedora infrastructure for using Fedora RPMs as the basis for the
bundled libraries, and tracking them, and rebuilding affected Flatpaks
when there is a security problem. And stuff that's bundled frequently
enough could probably just go into the Fedora runtime.
In scenarios where Flatpaks are shipped by upstream, they will also
have to
rebuild the library in some way, or wait for their distribution to
update
the package. But in addition, most upstreams will probably just do
cumulative updates of the libraries when they do a new release of
their own
code (if at all!) and not do timely security updates at all.
There is also the efficiency issue of having to update the whole
bundle,
which will encourage cumulative updates and discourage quick security
updates. If the bundle is updated for every library security update,
there
will be a lot to download. People are already complaining about the
size of
Fedora updates as it stands, without having to update dozens of huge
bundles
whenever a commonly used library is updated.
And it is also not possible to just stuff all libraries into the
runtime to
avoid this issue, because then the runtime becomes a huge pile of
libraries
that the user may or may not actually use, and updating the runtime
(which
would have to be done the more frequently the more libraries it
contains)
becomes very inefficient due to its size.
Yes, these are all real disadvantages. And of course there is an
inherent trade-off in the decision to include more libraries in the
runtime. I think we'll probably want a fairly large runtime for Fedora,
though, to reduce the amount of stuff that has to be bundled in
Flatpaks. (I believe all updates are delta updates, so if only one part
of the runtime changes, the update shouldn't be too large.)
> You forgot the positive changes such as:
> - sandboxing
> - dogfooding and testing for the sandboxing technologies
There ought to be better ways to sandbox applications than to turn
them into
what is essentially a full container (i.e., almost a full VM, only
minus the
kernel), bundling all the libraries. The split into an application
and a
runtime that Flatpak does is only a partial workaround.
I don't think there are better ways to sandbox applications. Sandboxing
is what has really sold me on Flatpak. The other main benefit of
Flatpaks is that independent application distribution becomes much
easier, which is very important for Fedora, but not at all a reason to
replace Fedora packages with Flatpaks. But sandboxing desktop
applications is a good reason to do so. We have the opportunity to
hugely improve the security of our operating system, and we should take
it. The benefits of this sandboxing outweigh the security costs of
increased library bundling. We will certainly have to be vigilant to
ensure Flatpaks are routinely updated when there is a security problem
in a bundled library, but if we are a little too slow, the sandbox will
often mitigate the problem. In effect, most successful exploits are now
going to require two different zero-days: one for the target
application, and one for the sandbox. That's huge.
We really need sandboxing technologies that work with shared system
libraries (also allowing the code segments to be shared in RAM). And
in
fact, we already have those technologies:
* Fedora ships and heavily promotes SELinux, which in fact, as far as
I
know, is also part of the sandboxing technologies Flatpak uses.
I kinda agree here (though I am a bit surprised, as I did not think you
were a very big SELinux fan). We absolutely could be investing more in
SELinux. But we have not been. Very few applications actually have
SELinux profiles, and they are all maintained downstream rather than
upstream. The volume of erroneous SELinux denials in Bugzilla is too
high, and the response time for fixing them too slow. SELinux profiles
work best when they are maintained upstream by application developers
who are familiar with SELinux, not by SELinux developers who are
unfamiliar with the application. But application developers who are
familiar with SELinux basically do not exist, and never will. So it
would be useful to have a general sandbox that works for the vast
majority of desktop apps.
* seccomp also looks very promising. Chromium (and QtWebEngine) is
already
using it effectively.
Yes and yes, both are true. But also: noooooo. seccomp is useful to
supplement a general purpose sandbox, but it's not suitable to be the
primary sandboxing mechanism. A secure, restrictive seccomp policy is
extremely, *extremely* brittle: if a library you depend on starts using
a new syscall, your application is going to crash. So it either
requires bundling libraries, or else never updating system libraries.
It is basically impossible to use them to construct an effective
restrictive sandbox unless it is highly targeted to a specific
application that bundles its dependencies and is maintained by a large
team of experienced developers. That's why it works well for Chromium.
(The team maintaining the Chromium sandbox is very good; they have gone
so far as to block calling syscalls with specific flags that they know
Chromium never uses, just to reduce the kernel attack surface.) I tried
a similar approach for WebKit a few years ago and quickly found it to
be completely unworkable; my favorite anecdote is how a Fedora update
to libxshmfence caused pages to not render anymore, because
libxshmfence started using a new syscall (it was memfd_create) that was
not whitelisted by the sandbox. We can't have that. Another anecdote
is the new seccomp sandbox for tracker-extract: whenever a GStreamer
plugin starts using a new unexpected syscall, or if you just happen to
have unexpected plugins installed, tracker-extract will crash. The
sandbox has to know everything about every possible GStreamer plugin
(so hope you never write your own custom one!). tracker is not the
greatest example here, because it is not an application, but my point
is that seccomp certainly cannot be used to construct a restrictive,
general-purpose sandbox, because applications are different and use
different syscalls. So if you're going to use seccomp as your primary
sandboxing mechanism, you'd better bundle all your libraries and not
allow any plugins. (I don't think you'd like that very much. ;)
Now, seccomp *is* very useful for just blocking off a few naughty
syscalls that applications have no business ever using. So yes, that's
promising. Flatpak actually already uses seccomp for this purpose. But
it's not a good choice to be our primary sandboxing mechanism.
Bundling libraries has many drawbacks, including security-related
ones (as I
explained above). (It also wastes download bandwidth, disk space, and
RAM.)
To really improve security, we must provide the benefits of sandboxing
without bundling libraries.
It's certainly a trade-off. I think the security benefit of the Flatpak
sandbox greatly outweighs the security cost of bundling libraries. But
I'm also worried that we might not develop tools for tracking outdated
bundled libraries in Flatpak applications. We'll need to.
Regarding bandwidth and disk space... I think we need to wait and see
and evaluate how things turn out. Certainly, if you have a bunch of
different Flatpak runtimes installed, there are going to be space costs
and bandwidth costs, and at a certain point that will be too
undesirable. So this is also a valid concern.
> - more efficient update tracking than RPM (eg. no need to
download
> 20 megs
> of metadata to know there's nothing to update)
But less efficient updating, because you will need to download much
more
than 20 megs of bundled libraries. The only reason the metadata is
smaller
is because there is almost no dependency information encoded (only a
single
dependency on a runtime). But those dependencies are what makes
installing
and updating packages so efficient! Flatpak throws away the main
competitive
advantage of GNU/Linux!
Yes, but remember that Flatpak is only for desktop applications. The
majority of your OS is still going to be packages.
Michael
2:46 a.m.
On 2017-07-12, mcatanzaro(a)gnome.org <mcatanzaro(a)gnome.org> wrote:
Very few applications actually have SELinux profiles, and they are
all
maintained downstream rather than upstream. The volume of erroneous
SELinux denials in Bugzilla is too high, and the response time for
fixing them too slow. SELinux profiles work best when they are
maintained upstream by application developers who are familiar with
SELinux, not by SELinux developers who are unfamiliar with the
application.
The issue with SELinux is that it's monolithic and program-centeric. You
cannot write a SELinux policy that keeps pace with updated libraries.
E.g. you have a program that resolves user names to UIDs via glibc. If
nsswitch changes it's configuration to use LDAP, the program starts
making TCP connection. Or you have a program that links to a library
that enables JIT and then the program starts requiring writetable and
executable memory mapping.
So a change in a dependency out of control of the program upstream
invalidates the policy. That's the reason why SELinux policy is
maintained downstream.
-- Petr
6:53 a.m.
mcatanzaro(a)gnome.org wrote:
> In the discussed approach where the Flatpak is composed from
RPMs, the
> library is updated by upstream, packaged, the Flatpak is rebuilt with
> the
> new library, and that is delivered to the user. So the extra step
> happens
> between the packaging of the library and the delivery to the user.
Maybe. I'm not sure about this. I believe the Flatpaks we're initially
planning to distribute will be composed from *Fedora* RPMs... not
upstream Flatpaks, at least not at first. So it should be possible to
build Fedora infrastructure for using Fedora RPMs as the basis for the
bundled libraries, and tracking them, and rebuilding affected Flatpaks
when there is a security problem. And stuff that's bundled frequently
enough could probably just go into the Fedora runtime.
It is true that automatically rebuilding the Flatpak if one of the RPMs it
is composed of has changed can speed up things a bit. I think there would
still be delays incurred in practice though.
I kinda agree here (though I am a bit surprised, as I did not think
you
were a very big SELinux fan). We absolutely could be investing more in
SELinux. But we have not been. Very few applications actually have
SELinux profiles, and they are all maintained downstream rather than
upstream. The volume of erroneous SELinux denials in Bugzilla is too
high, and the response time for fixing them too slow. SELinux profiles
work best when they are maintained upstream by application developers
who are familiar with SELinux, not by SELinux developers who are
unfamiliar with the application. But application developers who are
familiar with SELinux basically do not exist, and never will. So it
would be useful to have a general sandbox that works for the vast
majority of desktop apps.
Of course, I agree about those issues with SELinux, that is exactly why I
don't like it (and in fact don't even have it enabled, to be honest). I
think the main issue is really that the policy is mandated centrally rather
than being opted in by the individual application. The seccomp approach is
much better there, but…
Yes and yes, both are true. But also: noooooo. seccomp is useful to
supplement a general purpose sandbox, but it's not suitable to be the
primary sandboxing mechanism. A secure, restrictive seccomp policy is
extremely, *extremely* brittle: if a library you depend on starts using
a new syscall, your application is going to crash. So it either
requires bundling libraries, or else never updating system libraries.
It is basically impossible to use them to construct an effective
restrictive sandbox unless it is highly targeted to a specific
application that bundles its dependencies and is maintained by a large
team of experienced developers. That's why it works well for Chromium.
(The team maintaining the Chromium sandbox is very good; they have gone
so far as to block calling syscalls with specific flags that they know
Chromium never uses, just to reduce the kernel attack surface.) I tried
a similar approach for WebKit a few years ago and quickly found it to
be completely unworkable; my favorite anecdote is how a Fedora update
to libxshmfence caused pages to not render anymore, because
libxshmfence started using a new syscall (it was memfd_create) that was
not whitelisted by the sandbox. We can't have that. Another anecdote
is the new seccomp sandbox for tracker-extract: whenever a GStreamer
plugin starts using a new unexpected syscall, or if you just happen to
have unexpected plugins installed, tracker-extract will crash. The
sandbox has to know everything about every possible GStreamer plugin
(so hope you never write your own custom one!). tracker is not the
greatest example here, because it is not an application, but my point
is that seccomp certainly cannot be used to construct a restrictive,
general-purpose sandbox, because applications are different and use
different syscalls. So if you're going to use seccomp as your primary
sandboxing mechanism, you'd better bundle all your libraries and not
allow any plugins. (I don't think you'd like that very much. ;)
… you are right about the libraries. SELinux also has this issue, by the
way, as Petr Pisar correctly pointed out.
This is actually an issue even for QtWebEngine:
https://bugzilla.redhat.com/show_bug.cgi?id=1438973
I think it would really help if we had a way for libraries to declare their
own seccomp rules rather than forcing the application to guess.
It is clear that confining applications to a container helps sandboxing a
lot. But there ought to be a way to do it without physically duplicating
everything. How about building a virtual file system view (file system
namespacing exists in the kernel these days, doesn't it?) that contains a
read-only view of the system /usr (and possibly other needed directories),
together with other directories mounted off a container image or a tmpfs? If
the kernel part is done right for this purpose, even sharing read-only code
segments of the shared libraries in RAM should work across the file system
namespaces, as long as the actually referenced inode is the same. Think of a
"virtual Flatpak" that is just a runtime view into system directories, using
system binaries.
I am sure that there is a way to throw out the bathwater without the baby.
Rushing to deploy the current, very suboptimal solution is a very bad idea.
I am deeply convinced that the package system, which has served GNU/Linux
well for years and is its main advantage over proprietary operating systems,
is the way to go, and sandboxing can be adapted to it, not the other way
round. If it means it will take more time until it can be deployed, then we
should wait for that amount of time. Once everything moved from RPMs to
Flatpaks, it will be a lot harder to move back.
And in the end, to be honest, if I really have to choose between dependency
resolution or sandboxing, I will pick the former. If this means I can no
longer use Fedora, then I will have to look for another distribution,
unfortunately.
Yes, but remember that Flatpak is only for desktop applications. The
majority of your OS is still going to be packages.
When I see the plans that are floated around, the other stuff might also end
up being containerized in a similar way, just using other technologies
(e.g., Docker).
Kevin Kofler
7:44 a.m.
----- Original Message -----
<snip>
> - make it possible to create Flatpaks quicker for some more
complicated
> apps
That just requires shipping the tools for third parties to use, not using
them to deliver software packaged by Fedora.
The tooling is koji and bohdi. Shipping them isn't enough, hosting them is
necessary as well.
> - developers not having to learn GPG to sign their releases
That is a very weak argument. It is very straightforward to set up an RPM
signing key, not any harder than writing a specfile. And then you just run
rpmsign --addsign to sign the RPMs.
And in the end, you are just saying that Flatpak does away with a critical
security feature. Relying exclusively on the sandboxing for security is a
very bad idea. Sandbox evasion exploits exist.
"developers not having to learn GPG to sign their *Flatpak* releases"
I really don't understand how you misinterpreted that sentence so badly,
individual Fedora developers never had to GPG sign their Fedora packages...
> - more efficient update tracking than RPM (eg. no need to
download 20 megs
> of metadata to know there's nothing to update)
But less efficient updating, because you will need to download much more
than 20 megs of bundled libraries.
You download deltas, so the downloading is unlikely to be any worse than
downloading packaged updates. It also means I can update individual apps
without guesswork.
The only reason the metadata is smaller
is because there is almost no dependency information encoded (only a single
dependency on a runtime). But those dependencies are what makes installing
and updating packages so efficient! Flatpak throws away the main competitive
advantage of GNU/Linux!
It's not efficient if I need to download 20 megs of data to see that I have
nothing to update. I really don't see why dependencies make installing and
updating packages "so efficient".
And it is actually possible to solve the metadata size issue, see the
work
on metadata deltas. (There was at least one talk at DevConf on this.)
Right. It's just not done yet.
I started replying from the bottom of the mail, but I stopped midway. The
number of unsubstantiated claims got the better of me.
10:37 a.m.
After reading this, I think there's a false dichotomy here:
On Tue, Jul 11, 2017 at 9:26 PM, <mcatanzaro(a)gnome.org> wrote:
On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler
<kevin.kofler(a)chello.at>
wrote:
>
> There ought to be better ways to sandbox applications than to turn them
> into
> what is essentially a full container (i.e., almost a full VM, only minus
> the
> kernel), bundling all the libraries. The split into an application and a
> runtime that Flatpak does is only a partial workaround.
I don't think there are better ways to sandbox applications. Sandboxing is
what has really sold me on Flatpak.
Flatpak provides two things that are very nearly orthogonal: packaging
and sandboxing. Packaging is the system of bundles, apps, runtimes,
etc that allows you to build a Flatpak, send it to a different
machine, and run it there, even if the other machine runs a different
distro.
Sandboxing is Flatpak's system of portals, confinement, etc.
Aside from the fact that both are based on namespaces, I see no reason
at all that they need to be conflated. It should be entirely possible
for Flatpak ro run an "app" that is actually a conventional RPM
installed on the host system using host libraries. Flatpak would just
map all of /usr into its namespace rather than mapping a container
bundle into its namespace. The sandbox would work exactly the same as
for any other Flatpak except that the sandboxed app would be able to
read all of /usr. Arguably, in a model where all of /usr is visible
in the app's namespace, development and debugging might be
considerably easier.
Perhaps Fedora should consider a scheme where graphical application
RPMs are augmented with the metadata needed to run them inside Flatpak
while still packaging them the old-fashioned way with old-fashioned
RPM library dependencies and old-fashioned build tools. This would
almost certainly entail modifications to Flatpak, but I bet they'd be
fairly minor modifications and quite possibly much less complex than
all the tooling needed to get the average graphical application RPM to
build a functional Flatpak bundle.
--Andy
2:33 p.m.
On 07/12/2017 05:44 AM, Bastien Nocera wrote:
"developers not having to learn GPG to sign their *Flatpak*
releases"
I really don't understand how you misinterpreted that sentence so badly,
individual Fedora developers never had to GPG sign their Fedora packages...
That "*Flatpak*" was not in the original sentence and it really confused
me too. I was pretty sure individual maintainers didn't sign the RPMs,
so I wondered why that was a benefit of flatpaks. So now I understand
that the point is that Fedora signs the flatpaks instead of the
developers of the applications.
5:36 p.m.
Samuel Sieb wrote:
On 07/12/2017 05:44 AM, Bastien Nocera wrote:
> "developers not having to learn GPG to sign their *Flatpak* releases"
>
> I really don't understand how you misinterpreted that sentence so badly,
> individual Fedora developers never had to GPG sign their Fedora
> packages...
That "*Flatpak*" was not in the original sentence and it really confused
me too. I was pretty sure individual maintainers didn't sign the RPMs,
so I wondered why that was a benefit of flatpaks. So now I understand
that the point is that Fedora signs the flatpaks instead of the
developers of the applications.
If I ship third-party packages in a third-party repository on my own
infrastructure (see repo.calcforge.org), I do have to sign them myself.
The way I understood the sentence was that Flatpaks shipped on third-party
sites don't have to be signed. This is apparently not the case, and what
Bastien really meant is that Koji will take care of the signing for Flatpaks
built in Koji as it does for RPMs built in Koji. But that was not clear from
what he originally wrote.
Kevin Kofler
11:53 p.m.
On Wed, Jul 12, 2017 at 01:53:23PM +0200, Kevin Kofler wrote:
It is clear that confining applications to a container helps
sandboxing a
lot. But there ought to be a way to do it without physically duplicating
everything. How about building a virtual file system view (file system
namespacing exists in the kernel these days, doesn't it?) that contains a
read-only view of the system /usr (and possibly other needed directories),
together with other directories mounted off a container image or a tmpfs?
It's
already possible to some extent with systemd directives, for system
applications:
DynamicUser=yes or dedicated user with User=,
+ InaccessiblePaths to "subtract" + BindReadOnlyPaths to "add",
and PrivateTmp/Private*/ProtectSystem + SystemCallFilter to implement the
sandbox.
(Or maybe RootImage or RootDirectory should be used to construct the
visible file system from scratch, binding in "external" stuff using
BindPaths and BindReadOnlyPaths. Dunno.)
Of course none of this is competition for flatpack currently, because
it's not automatized and requires privileges.
It would be interesting how to see how far this can be taken.
Zbyszek
10:55 a.m.
On Thu, 2017-07-13 at 00:36 +0200, Kevin Kofler wrote:
Koji will take care of the signing for Flatpaks
built in Koji as it does for RPMs built in Koji.
Sigul[0] is actually the system that signs the packages. They are
placed into a Koji tag when they need to be signed, and when Sigul is
done signing them it moves them into a new Koji tag.
[0] https://pagure.io/sigul
3:44 a.m.
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
F29: packagers (of graphical applications) must create Flatpaks of
their applications if possible. They *may* keep standard RPM
packaging.
At least we see where this is going.
If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks? Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:32 a.m.
On Friday, 14 July 2017 at 10:44, Richard W.M. Jones wrote:
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> F29: packagers (of graphical applications) must create Flatpaks of
> their applications if possible. They *may* keep standard RPM
> packaging.
At least we see where this is going.
If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks? Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.
Is `dnf install foo' still going to work when foo is converted to a
Flatpak and no longer built as a plain RPM? In my opinion, that's
a prerequisite to dropping any RPMs in favour of Flatpaks. I'm fine
with introducing Flatpaks alongside RPMs as an option, but I'm against
forcing packagers to switch to Flatpaks as the primary distribution
format if the existing package management tools do not support it.
From what I read, only GNOME Software app supports Flatpaks and not
everyone uses GNOME Software to install software.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
8:28 a.m.
Richard W.M. Jones wrote:
If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks? Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.
+1, completely!
I think it is completely unacceptable to REPLACE RPMs with Flatpaks, and
this is exactly why I am so much opposed to this innocuous-sounding change
proposal that is just the beginning of the slippery slope.
Kevin Kofler
8:32 a.m.
Owen Taylor wrote:
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.
This sounds a lot like:
https://en.wikipedia.org/wiki/Salami_tactics
to me, a common strategy used by construction companies to subvert
environmental rules, obviously frowned upon. You are trying to submit small
innocous-sounding changes in an attempt to sneak in your plan to completely
subvert Fedora while minimizing opposition.
I really hope that FESCo will evaluate the above complete plan when
considering your change proposal, not just the thin salami slice that you
submitted.
Kevin Kofler
8:58 a.m.
* Dominik 'Rathann' Mierzejewski [14/07/2017 13:32] :
Is `dnf install foo' still going to work when foo is converted to a
Flatpak and no longer built as a plain RPM?
I was unable to find Recipes (an application in the latest GNOME) either
by dnf or Gnome Software. Using Google, I found out this app is only
available via flatpak and that installing and upgrading it requires using
the flatpak commands instead of the dnf/Gnome Software ones.
Emmanuel
9:11 a.m.
On Fri, Jul 14, 2017 at 03:32:03PM +0200, Kevin Kofler wrote:
Owen Taylor wrote:
> 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.
This sounds a lot like:
https://en.wikipedia.org/wiki/Salami_tactics
to me, a common strategy used by construction companies to subvert
environmental rules, obviously frowned upon. You are trying to submit small
innocous-sounding changes in an attempt to sneak in your plan to completely
subvert Fedora while minimizing opposition.
I really hope that FESCo will evaluate the above complete plan when
considering your change proposal, not just the thin salami slice that you
submitted.
Well, let's be fair here, if it was indeed what you are describing, would it be
announced on this list 1.5 years in advance ?
Pierre
9:42 a.m.
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
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.
If I look at this from my POV as the upstream maintainer of a graphical
application wishing to make it widely available to users of many distros.
The question is whether it is beneficial for me to join Fedora packaging
world to package my app, or whether to package it standalone as a flatpak
and never get involved in Fedora at all.
With the proposed F27 rule here, I would have less work todo if I just
built my app as a flatpak, as I can avoid creating RPMs and just build
a single flatpak that should work on all distros. IOW by mandating
continued creation of RPMs, alongside flatpaks, we would be discouraging
people from becoming Fedora maintainers.
Thus could suggest more flexibility - require continued maint of RPMs
for *existing* applications in Fedora only, to give some grace period
where we figure out how to provide a seemless upgrade path for people
who have an existing RPM installed to magically replace it with flatpak.
Anyone wishing to package a *new* application in F27, however, should be
able to straight to flatpaks only as there's no upgrade path issue to
worry about.
This would encourage upstream app maintainers to join Fedora to make
use of the review, build & distribution mechanisms for flatpaks, without
forcing them todo extra work to create RPMs too.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:50 a.m.
On Wed, Jul 12, 2017, at 07:53 AM, Kevin Kofler wrote:
When I see the plans that are floated around, the other stuff might also end
up being containerized in a similar way, just using other technologies
(e.g., Docker).
There are definitely apps today that are designed to run in standalone Docker/OCI
containers, and even more that *solely* target Kubernetes/OpenShift.
So on the server side, we are definitely going to be crossing the same bridge
here for desktop apps - some software in Fedora will be container only, and
any RPMs that we might generate for it are only intermediate forms, not user-facing.
It is a bit silly to put them in Fedora Everything, hence aligning container builds
with Modularity help in the same way it will for flatpak.
11:59 a.m.
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> F29: packagers (of graphical applications) must create Flatpaks of
> their applications if possible. They *may* keep standard RPM
> packaging.
At least we see where this is going.
If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks? Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.
Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
12:05 p.m.
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> F29: packagers (of graphical applications) must create Flatpaks of
> their applications if possible. They *may* keep standard RPM
> packaging.
At least we see where this is going.
If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks? Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.
How about reliable online updates of running applications as a
benefit?
12:26 p.m.
On Fri, Jul 14, 2017 at 05:05:23PM +0000, Debarshi Ray wrote:
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
How about reliable online updates of running applications as a
benefit?
AND the ability to roll back, to choose beta or stable streams, etc.
For example, the Google Play app store, you can check a box to opt in
to beta versions of an app you're interested in following the bleeding
edge of. It'd be awesome to do that in Fedora. We *could* do that with
traditional packaging, but in practice doing it well seems like at
least as much work as the flatpak bundle approach — and we still
wouldn't get the update advantage.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:36 p.m.
On Fri, Jul 14, 2017 at 1:27 PM Matthew Miller <On Fri, Jul 14, 2017 at
05:05:23PM +0000, Debarshi Ray wrote:
> How about reliable online updates of running applications as a
> benefit?
AND the ability to roll back, to choose beta or stable streams, etc.
These are reasonably good advantages but if there isn't a seamless
transition between them, it induces a lot of pain. For instance, dnf
cannot install flatpak apps currently and I can't use kickstart to automate
installation in the same way etc.
Rahul
1:12 p.m.
On Fri, Jul 14, 2017 at 9:59 AM, Debarshi Ray <rishi.is(a)lostca.se> wrote:
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > F29: packagers (of graphical applications) must create Flatpaks of
> > their applications if possible. They *may* keep standard RPM
> > packaging.
>
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
As above, it could be the exact same sandbox technology with the same
portals and everything. The sandboxed program would just be files in
/usr instead of a Flatpak.
--Andy
1:25 p.m.
On 14 July 2017 at 12:32, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
From what I read, only GNOME Software app supports Flatpaks and not
everyone uses GNOME Software to install software.
Maybe tangential to the proposal/discussion/ranting, but you can
actually use gnome-software on the command line.
/usr/libexec/gnome-software-cmd (no GTK parts get loaded) has got a
bit cleverer in F26 and is set to get even cleverer in F27. With this
tool you can install/remove/update flatpaks, packages, gnome shell
extensions, and even update firmware. It's not quite ready for human
consumption (it's designed as a debug tool), but it could quite easily
be moved into /usr/bin/ and a man page be written. I don't think
"teach dnf about everything" is a super practical plan.
Richard.
1:30 p.m.
On 14 July 2017 at 19:12, Andrew Lutomirski <luto(a)mit.edu> wrote:
As above, it could be the exact same sandbox technology with the
same
portals and everything. The sandboxed program would just be files in
/usr instead of a Flatpak.
How could that work? The runtime gets mounted in /usr and the app gets
mounted in /app in a different place.
https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
read.
Richard.
2:05 p.m.
One major reason is that it enables us to move towards having the Atomic Workstation
version be the primary one and maybe in the (very) long run be the only one.
A bit more detail about that can be found here:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
Or this talk from FLOCK by Patrick Uiterwijk:
https://www.youtube.com/watch?v=zduGfpfwHz4
Christian
----- Original Message -----
> From: "Richard W.M. Jones" <rjones(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Sent: Friday, July 14, 2017 4:44:18 AM
> Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks
>
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > F29: packagers (of graphical applications) must create Flatpaks of
> > their applications if possible. They *may* keep standard RPM
> > packaging.
>
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines. Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
2:28 p.m.
2017-07-14 19:05 GMT+02:00 Debarshi Ray <rishi.is(a)lostca.se>:
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > F29: packagers (of graphical applications) must create Flatpaks of
> > their applications if possible. They *may* keep standard RPM
> > packaging.
>
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
How about reliable online updates of running applications as a
benefit?
Is this really more reliable than using dnf (for graphical packages
like Recepies and Builder)? What exactly is it that makes flatpaks
more reliable?
/Andreas
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
2:29 p.m.
On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanzaro(a)gnome.org wrote:
But we have not been. Very few applications actually have SELinux
profiles,
and they are all maintained downstream rather than upstream. The volume of
erroneous SELinux denials in Bugzilla is too high, and the response time for
fixing them too slow. SELinux profiles work best when they are maintained
upstream by application developers who are familiar with SELinux, not by
SELinux developers who are unfamiliar with the application.
We do have the same issue with sandbox policies for Flatpak, no? This
is the hard part of any sandboxing system and (judging from the current
docs) Flatpak hasn't tackled it yet.
A Flatpak app currently requires the following incantation to access the
host's dconf, so that it can behave like its users would expect:
--filesystem=xdg-run/dconf
--filesystem=~/.config/dconf:ro
--talk-name=ca.desrt.dconf
--env=DCONF_USER_CONFIG_DIR=.config/dconf
Now, while this specific dconf issue might get solved at some point,
dconf won't be enough for the vast majority of useful apps. All the crap
that lives in the various dot files in your home directory and elsewhere
on the system and that affects the behaviour of a program needs to be
made available to the app. Other things must not be, such as everything
containing secrets.
Some apps (e.g. virt-manager) need access to your ssh-agent socket but
you certainly don't want to make it available to every single app. This
is just a single instance of the general case of a program talking to
one of the numerous services that may run on the host.
programs depending on user configuration.
You want some environment variables passed through to the sandboxed app
(EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the
Flatpak app even going to execute your favorite editor?
Someone is going to have to write all the policy for that. Otherwise,
the only apps that Flatpak will be able to handle properly are going to
be trivial mobile-style apps that don't interact with anything but their
developer's cloud services.
2:54 p.m.
On 07/12/2017 06:26 AM, mcatanzaro(a)gnome.org wrote:
I kinda agree here (though I am a bit surprised, as I did not think
you
were a very big SELinux fan). We absolutely could be investing more in
SELinux. But we have not been. Very few applications actually have
SELinux profiles, and they are all maintained downstream rather than
upstream. The volume of erroneous SELinux denials in Bugzilla is too
high, and the response time for fixing them too slow. SELinux profiles
work best when they are maintained upstream by application developers
who are familiar with SELinux, not by SELinux developers who are
unfamiliar with the application. But application developers who are
familiar with SELinux basically do not exist, and never will. So it
would be useful to have a general sandbox that works for the vast
majority of desktop apps.
On the other hand, most upstreams, even if they know about SELinux, will
rarely adopt restrictive policies. They are also not modular in the
sense that you can write a policies for an application without taking
their library dependencies into account, or policies for libraries
without examining how applications use the library. And when it comes
to rarely used features, I don't think many upstreams would implement
them and then prevent their use with a security policy.
The app store model also assumes that the app store operator acts as
some sort of gate keeper, so there has to be some policy enforcement at
this level, too. It is not sufficient to pass through just what the
application developer asked for.
Thanks,
Florian
3:32 p.m.
On Fri, Jul 14, 2017 at 07:25:11PM +0100, Richard Hughes wrote:
Maybe tangential to the proposal/discussion/ranting, but you can
actually use gnome-software on the command line.
/usr/libexec/gnome-software-cmd (no GTK parts get loaded) has got a
bit cleverer in F26 and is set to get even cleverer in F27. With this
tool you can install/remove/update flatpaks, packages, gnome shell
extensions, and even update firmware. It's not quite ready for human
consumption (it's designed as a debug tool), but it could quite easily
be moved into /usr/bin/ and a man page be written. I don't think
"teach dnf about everything" is a super practical plan.
I dunno about "practical", but "one unified commandline tool to manage
all the software on my system" sure is *nice* from a user and admin
perspective. Maybe the dnf tool could be a plugin wrapper around
/usr/libexec/gnome-software-cmd?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4:04 p.m.
On 14 July 2017 at 20:28, Andreas Tunek <andreas.tunek(a)gmail.com> wrote:
Is this really more reliable than using dnf (for graphical packages
like Recepies and Builder)?
It's hugely more reliable. You can't actually trust rpm to do anything
atomically, and this is the main reason we force upgrade to be offline
in the workstation product. Just doing this one step reduced the
number of people experiencing the dead-system-after-upgrading bugs by
two order of magnitude, but it SUCKS to have to reboot to apply
application updates. Doing live updates with rpm is a bit like doing
maintenance on your car engine while driving down the freeway. Most of
the time it's fine, and you feel awesome. 0.001% of the time you die
in a huge fireball.
What exactly is it that makes flatpaks
more reliable?
They are *designed* to be updated atomically. You can safely update
application from a->b->c all running any permutation of running
processes and flatpak makes sure that the running app is only cleaned
up when the last instance is closed. RPM is an awesome system for
building the OS, just not managing *apps*. Flatpak is that awesome
thing for apps.
Richard, the man that gets to triage the "live updates hosed my system" bugs.
4:48 p.m.
On Fri, 14 Jul 2017 19:30:18 +0100
Richard Hughes <hughsient(a)gmail.com> wrote:
How could that work? The runtime gets mounted in /usr and the app
gets
mounted in /app in a different place.
https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
read.
I just read that. I'm ignorant of flatpak except for seeing it
mentioned here and reading that. I have a ton of questions about
how this is going to work, and a lot of misgivings, but I'll just
lurk for most of them, as they are questions that are going to have
to be answered in the course of development. One I would like
answered, though, is what would be the difference in size for a binary
rpm of, say, gedit and a flatpak of gedit? It sounds like a flatpak is
many times larger than a binary rpm. Is that true?
4:52 p.m.
On Jul 14, 2017, at 11:30 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
> On 14 July 2017 at 19:12, Andrew Lutomirski <luto(a)mit.edu> wrote:
> As above, it could be the exact same sandbox technology with the same
> portals and everything. The sandboxed program would just be files in
> /usr instead of a Flatpak.
How could that work? The runtime gets mounted in /usr and the app gets
mounted in /app in a different place.
https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
read.
I don't see the problem. The runtime could be all of /use and the app
could be a symlink living in /app that points at /usr. The latter
could be created on the fly in a tmpfs.
Or the flatpak runtime could learn to accept a special type of
manifest that just says to run /usr/bin/whatever and not worry about
/app.
4:56 p.m.
On Jul 14, 2017, at 12:54 PM, Florian Weimer
<fweimer(a)redhat.com> wrote:
The app store model also assumes that the app store operator acts as
some sort of gate keeper, so there has to be some policy enforcement at
this level, too. It is not sufficient to pass through just what the
application developer asked for.
This is only a problem because Flatpak is currently following the IMO
rather busted old Android model. With very few, if any, exceptions, I
think a much better model would be for an application to start with
basically no permissions and to have to ask for fine-grained
permissions as needed. Think iOS but tighter. By default, an app
shouldn't be able to use the network, see what other applications are
installed, or get your unique advertising ID without explicit consent,
let alone access your dotfiles.
I would like to see a situation in which running random Flatpaks is as
safe or safer than visitng random webpages, at least insofar as the
*intentional* surface by which it can damage you should be as small or
smaller than that of a webpage.
6:15 a.m.
On 14.07.2017 19:36, Rahul Sundaram wrote:
On Fri, Jul 14, 2017 at 1:27 PM Matthew Miller <On Fri, Jul 14,
2017 at
05:05:23PM +0000, Debarshi Ray wrote:
>
>> How about reliable online updates of running applications as a
>> benefit?
>
> AND the ability to roll back, to choose beta or stable streams, etc.
>
These are reasonably good advantages but if there isn't a seamless
transition between them, it induces a lot of pain. For instance, dnf
cannot install flatpak apps currently and I can't use kickstart to automate
installation in the same way etc.
Arguably dnf should never support flatpaks as that is not its job.
Instead there should probably a tool (called "app"?) that sits on top of
the lower-level dnf and flatpak tools that abstracts the idea of
installing software away from the delivery mechanism (rpm, flatpak).
"app install blender" would check both flatpak and rpm repositories and
install the latest version it finds (by using the dnf and flatpak
commands in the background).
Regards,
Dennis
11:36 a.m.
On Thu, Jul 13, 2017 at 11:55:52AM -0400, Randy Barlow wrote:
On Thu, 2017-07-13 at 00:36 +0200, Kevin Kofler wrote:
> Koji will take care of the signing for Flatpaks
> built in Koji as it does for RPMs built in Koji.
So there is change really.
Before: developers sign tarball, packagers authenticate to Fedora, Fedora signs rpm
With flatpacks: developers sign tarball, packagers authenticate to Fedora, Fedora signs
flatpack
Same amount of links of trust, same amount of signatures. No?
> Sigul[0] is actually the system that signs the packages. They are
> placed into a Koji tag when they need to be signed, and when Sigul is
> done signing them it moves them into a new Koji tag.
>
> [0] https://pagure.io/sigul
12:17 p.m.
On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> 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.
If I look at this from my POV as the upstream maintainer of a graphical
application wishing to make it widely available to users of many distros.
The question is whether it is beneficial for me to join Fedora packaging
world to package my app, or whether to package it standalone as a flatpak
and never get involved in Fedora at all.
With the proposed F27 rule here, I would have less work todo if I just
built my app as a flatpak, as I can avoid creating RPMs and just build
a single flatpak that should work on all distros. IOW by mandating
continued creation of RPMs, alongside flatpaks, we would be discouraging
people from becoming Fedora maintainers.
Thus could suggest more flexibility - require continued maint of RPMs
for *existing* applications in Fedora only, to give some grace period
where we figure out how to provide a seemless upgrade path for people
who have an existing RPM installed to magically replace it with flatpak.
Anyone wishing to package a *new* application in F27, however, should be
able to straight to flatpaks only as there's no upgrade path issue to
worry about.
This would encourage upstream app maintainers to join Fedora to make
use of the review, build & distribution mechanisms for flatpaks, without
forcing them todo extra work to create RPMs too.
This depends on how exactly flatpacks are built:
- if first an rpm is built, and then flatpack is built out of rpms,
it's strictly more work (although there are benefits to users of installing
using flatpacks over plain rpms, so it's an actual benefit for users
and hence not pointless).
- if one is building a _leaf_ application, and all deps are available as
rpms, then the packager doesn't need to follow the strict rpm rules,
and if they only build a flatpack without the intermediate rpm,
some work is saved.
- if one is building an application that anything else depends on, things
get more complicated.
(Let's take inkscape as an example: it's a end-user graphical application,
but it has command-line mode where it converts svgs to pngs and such,
so it might be used e.g. when generating documentation or in %check
for another package.)
If inkscape is still available as rpm, it can be used as a dep in building
other rpms. If however inkscape suddenly becomes available only as a flatpack,
how does that work? Do we allow rpms to specify BuildRequires: inkscape.flatpack,
and koji will install it and make the application available?
Even if technically possible in the future, I don't think it's
something we'd want to commit to right now.
So in the end, flatpacks as an *additional* distribution mechanism
sound fine. But if they become the *only* distribution mechanism, we
risk that the whole ecosystem of packages which can all be used to
build one another falls apart.
(Maybe I'm seeing this wrong. Please explain how this can be avoided.)
Zbyszek
12:40 p.m.
On 15 July 2017 at 12:36, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> wrote:
On Thu, Jul 13, 2017 at 11:55:52AM -0400, Randy Barlow wrote:
> On Thu, 2017-07-13 at 00:36 +0200, Kevin Kofler wrote:
> > Koji will take care of the signing for Flatpaks
> > built in Koji as it does for RPMs built in Koji.
So there is change really.
Before: developers sign tarball, packagers authenticate to Fedora, Fedora signs rpm
With flatpacks: developers sign tarball, packagers authenticate to Fedora, Fedora signs
flatpack
Same amount of links of trust, same amount of signatures. No?
It depends on a couple of other steps that are dropped out. Currently
here is the level:
Developer releases source code.
Maybe they sign it or not.
Packager downloads source code.
Packager maybe checks signature of source code.
Packager authenticates to Fedora
Packager uploads source code
Packager updates/uploads spec file
Fedora builds source code into package using other signed/supported code.
Packager tests built package
Packager asks Fedora to sign package
Fedora signs package
Fedora puts package into testing
OS Testers download/test package
Fedora pushed package into release/updates
OS Users download/use package
Each of those steps has a specific trust chain to it. The part that
isn't clear with the FlatPack is that various people in these threads
have explained different chains of how FlatPacks are being delivered
to users. Those descriptions have gotten conflated multiple times by
both proponents and opponents to make it less clear how the entire
trust chain works.
Versions I have seen discussed as the Flatpack way.
1. Developer releases source code. Developer makes flatpack. Packager
uploads flatpack. Fedora signs it. Things test it. User gets it.
2. Developer releases source code. Developer signs source code.
Packager downloads and checks sig. Packager compiles flatpack.
Packager signs flatpack. Packager uploads to Fedora. Fedora checks and
signs it. Things test it. User gets it.
3. Dev releases source code. Dev signs source code. Pack downloads and
checks sig. Packager makes flatpack spec file. Packager uploads source
code and spec file to Fedora. Fedora builds flatpack. Fedora signs
flatpack. User gets it.
4. Developer releases source code. Someone makes a flatpack from
source code. Fedora tools point user to that flatpack whereever it is
and uses some sort of verification to 'trust it'.
5. ...
Each of those has a different trust path and when people say "Oh they
are are the same" they may be talking about 1 single version but
because someone else was talking about another there is disagreement.
Can we list this clearly?
> Sigul[0] is actually the system that signs the packages. They
are
> placed into a Koji tag when they need to be signed, and when Sigul is
> done signing them it moves them into a new Koji tag.
>
> [0] https://pagure.io/sigul
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
12:43 p.m.
On Fri, Jul 14, 2017 at 02:56:34PM -0700, Andrew Lutomirski wrote:
This is only a problem because Flatpak is currently following the
IMO
rather busted old Android model. With very few, if any, exceptions, I
think a much better model would be for an application to start with
basically no permissions and to have to ask for fine-grained
permissions as needed. Think iOS but tighter. By default, an app
shouldn't be able to use the network, see what other applications are
installed, or get your unique advertising ID without explicit consent,
let alone access your dotfiles.
I don't agree. With this model, every time you try to do something,
you're bombarded with questions asking if you want to do the thing you
tried to do. It gets very easy to fall into a default of clicking a
bunch of yesses all the time. That serves no *real* security benefit
and yet adds to user annoyance. There's gotta be a better way than
that.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:54 a.m.
On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > F29: packagers (of graphical applications) must create Flatpaks of
> > their applications if possible. They *may* keep standard RPM
> > packaging.
>
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
Things like libvirt-sandbox have been around for a really long time
and don't require special packaging (in fact they work with any
arbitrary command).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
5:54 a.m.
On Fri, Jul 14, 2017 at 01:26:21PM -0400, Matthew Miller wrote:
On Fri, Jul 14, 2017 at 05:05:23PM +0000, Debarshi Ray wrote:
> > At least we see where this is going.
> >
> > If RPMs of the graphical application work fine now, what on earth is
> > the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> > of them - as already explained, sandboxing is orthogonal to packaging.
>
> How about reliable online updates of running applications as a
> benefit?
AND the ability to roll back, to choose beta or stable streams, etc.
For example, the Google Play app store, you can check a box to opt in
to beta versions of an app you're interested in following the bleeding
edge of.
Sounds like it would be an excellent feature to add to rpm/dnf.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
5:56 a.m.
On Fri, Jul 14, 2017 at 10:04:37PM +0100, Richard Hughes wrote:
On 14 July 2017 at 20:28, Andreas Tunek
<andreas.tunek(a)gmail.com> wrote:
> Is this really more reliable than using dnf (for graphical packages
> like Recepies and Builder)?
It's hugely more reliable. You can't actually trust rpm to do anything
atomically,
Which could be fixed and the fix would benefit everyone ...
and this is the main reason we force upgrade to be offline
in the workstation product.
No, that's a workaround for not fixing it properly.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
6:25 a.m.
Christian Schaller wrote:
One major reason is that it enables us to move towards having the
Atomic
Workstation version be the primary one and maybe in the (very) long run be
the only one.
A bit more detail about that can be found here:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
And how is that a worthwhile goal to begin with? I see only disadvantages in
the Atomic model. No more fine-grained choice of packages, just a "take it
or leave it" blob. No more possibility to add additional repositories
replacing individual packages (in fact, it contradicts the modularity idea
that is also being planned). And to work around that, you force all
applications to be delivered as their own monolithic blobs duplicating all
the libraries that are already in the OS blob (either as part of a "Runtime"
or as part of the app itself).
I do NOT want an Atomic blob as my operating system. If Fedora forces its
users to use that, I will not use Fedora anymore.
Kevin Kofler
6:29 a.m.
Daniel P. Berrange wrote:
If I look at this from my POV as the upstream maintainer of a
graphical
application wishing to make it widely available to users of many distros.
The question is whether it is beneficial for me to join Fedora packaging
world to package my app, or whether to package it standalone as a flatpak
and never get involved in Fedora at all.
With the proposed F27 rule here, I would have less work todo if I just
built my app as a flatpak, as I can avoid creating RPMs and just build
a single flatpak that should work on all distros. IOW by mandating
continued creation of RPMs, alongside flatpaks, we would be discouraging
people from becoming Fedora maintainers.
From a user standpoint, what's the difference? What's the benefit from
having upstream deliver their software Flatpak-only under the Fedora
umbrella? It may as well come directly from upstream at that point. The
whole point of delivering software under the Fedora umbrella is to deliver
it as RPMs. If there is no RPM, delivering through Fedora is completely
useless.
Kevin Kofler
6:41 a.m.
Matthew Miller wrote:
I dunno about "practical", but "one unified
commandline tool to manage
all the software on my system" sure is *nice* from a user and admin
perspective. Maybe the dnf tool could be a plugin wrapper around
/usr/libexec/gnome-software-cmd?
I most definitely DON'T want my dnf to get infected with Flatpak and even
less with gnome-* anything!
Kevin Kofler
7:10 a.m.
Debarshi Ray wrote:
How about reliable online updates of running applications as a
benefit?
Upgrading RPM applications online just works. I do it all the time. The KDE
tools do not even implement offline updates (and IMHO that's a good thing).
The worst that can happen is that some recalcitrant applications (by far the
minority) need to be restarted after updating (or if you upgraded the whole
desktop, then your session may need to be restarted after updating). Until
you do that, the current session may be "hosed" to some extent, but
restarting will fix it. It is surely the lesser evil than forcing a complete
system reboot before the update as GNOME does now. I never had a hosed
system. In most cases, I just run the updates and continue working without
even restarting anything, it just works.
This issue is being deeply blown out of proportion.
Kevin Kofler
7:11 a.m.
Matthew Miller wrote:
AND the ability to roll back, to choose beta or stable streams, etc.
For example, the Google Play app store, you can check a box to opt in
to beta versions of an app you're interested in following the bleeding
edge of. It'd be awesome to do that in Fedora. We *could* do that with
traditional packaging, but in practice doing it well seems like at
least as much work as the flatpak bundle approach — and we still
wouldn't get the update advantage.
Opt-in:
su - (or sudo -i)
dnf copr enable myapp-beta
dnf distro-sync
Opt back out and roll back:
su - (or sudo -i)
dnf copr disable myapp-beta
dnf distro-sync
Where's the problem? This is also trivial to offer in a UI.
And the (unrelated) online update issue is really a non-issue in practice,
as I explained in my reply to Debarshi Ray.
Kevin Kofler
7:38 a.m.
On 07/16/2017 01:25 PM, Kevin Kofler wrote:
Christian Schaller wrote:
> One major reason is that it enables us to move towards having the Atomic
> Workstation version be the primary one and maybe in the (very) long run be
> the only one.
>
> A bit more detail about that can be found here:
> https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
And how is that a worthwhile goal to begin with? I see only disadvantages in
the Atomic model. No more fine-grained choice of packages, just a "take it
or leave it" blob. No more possibility to add additional repositories
replacing individual packages (in fact, it contradicts the modularity idea
that is also being planned). And to work around that, you force all
applications to be delivered as their own monolithic blobs duplicating all
the libraries that are already in the OS blob (either as part of a "Runtime"
or as part of the app itself).
I do NOT want an Atomic blob as my operating system. If Fedora forces its
users to use that, I will not use Fedora anymore.
Kevin Kofler
I completely agree with you, sounds like we lose flexibility and make
things much more complicated as they should be.
Greetings,
Christian
7:45 a.m.
On 07/14/2017 10:32 PM, Matthew Miller wrote:
On Fri, Jul 14, 2017 at 07:25:11PM +0100, Richard Hughes wrote:
> Maybe tangential to the proposal/discussion/ranting, but you can
> actually use gnome-software on the command line.
> /usr/libexec/gnome-software-cmd (no GTK parts get loaded) has got a
> bit cleverer in F26 and is set to get even cleverer in F27. With this
> tool you can install/remove/update flatpaks, packages, gnome shell
> extensions, and even update firmware. It's not quite ready for human
> consumption (it's designed as a debug tool), but it could quite easily
> be moved into /usr/bin/ and a man page be written. I don't think
> "teach dnf about everything" is a super practical plan.
I dunno about "practical", but "one unified commandline tool to manage
all the software on my system" sure is *nice* from a user and admin
perspective. Maybe the dnf tool could be a plugin wrapper around
/usr/libexec/gnome-software-cmd?
Please not, package manager is our way to distribute the software and
thus should never be coupled to any specific upstream projects which
could have a different view on things, make changes etc. and we have a
"possibility" of a broken package management. It has to work the other
way around, a plugin for DNF would be the solution for that. So a plugin
which can query gnome-software-cmd to get access to these additional
resources, but if anything is messed up, disable plugin → core package
management works again.
Greetings,
Christian
8:21 a.m.
On 07/10/2017 09:31 PM, Owen Taylor wrote:
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.
Perfectly fine :) Adds an additional, but optional, way of distribution.
I don't like Flatpak, but as long as I'm not forced and RPM is the
standard packaging, I just ignore it ;)
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.
So we could end up in a situation where neither Flatpak nor RPM provide
a complete package/application set? Would be bad… and also inconsistent.
Also: What additional work does Flatpak require for me as a packager? I
read something about automated builds, but then we would not need this
discussion and could create both worlds. As I have limited time, I'll
provide my packages in one consistent way, not multiple ways. As I have
both graphical applications and other stuff, that will be RPM for sure.
F29: packagers (of graphical applications) must create Flatpaks of
their applications if possible. They *may* keep standard RPM
packaging.
I hope we will *never* reach that point, if we reach it, I have to move
to another Linux distribution which follows the rules of construction I
prefer. As a packager I know how much many upstreams love bundling (and
not updating bundled libs), IMHO Flatpak (in general) encourages them to
do that (yes I know, they can do also for RPM, but Flatpak makes it
easy). And outdated libraries are a high security risk (heartbleed etc.
;)) and sandboxing can never save you from all possible impacts.
Sandboxing is an *additional* and as said in some other mail
*orthogonal* mechanism to clean packaging. I feel we lose many
advantages over operating systems like Windows if we open that door and
continue that way…
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.
That said, for the
optional availability of flatpak for packagers: I'm
perfectly fine with that, I'll just ignore it for my stuff. But if there
will be proposals which will change Fedora in a way that I think is
wrong, I'll be back to discuss them ;) Also I know from IRC that there
are more packagers thinking the same way.
Greetings,
Christian
8:39 a.m.
On Sun, Jul 16, 2017 at 01:29:01PM +0200, Kevin Kofler wrote:
Daniel P. Berrange wrote:
> If I look at this from my POV as the upstream maintainer of a graphical
> application wishing to make it widely available to users of many distros.
> The question is whether it is beneficial for me to join Fedora packaging
> world to package my app, or whether to package it standalone as a flatpak
> and never get involved in Fedora at all.
>
> With the proposed F27 rule here, I would have less work todo if I just
> built my app as a flatpak, as I can avoid creating RPMs and just build
> a single flatpak that should work on all distros. IOW by mandating
> continued creation of RPMs, alongside flatpaks, we would be discouraging
> people from becoming Fedora maintainers.
From a user standpoint, what's the difference? What's the benefit from
having upstream deliver their software Flatpak-only under the Fedora
umbrella? It may as well come directly from upstream at that point. The
whole point of delivering software under the Fedora umbrella is to deliver
it as RPMs.
The same difference as for software coming as a RPM from upstream compared
to an RPM in Fedora:
- we can patch stuff and adjust build options
- the user can trust Fedora more than upstream
(for licensing checks, for looking over the code, for being still
here next year to patch or rebuild the artifacts if needed)
If there is no RPM, delivering through Fedora is completely useless.
That's not even true today. We get stuff from Fedora in formats like
file system images and ostree repos, and they are quite useful.
Zbyszek
9:05 a.m.
Hi,
Kevin Kofler kirjoitti 16.07.2017 klo 15:11:
Matthew Miller wrote:
> AND the ability to roll back, to choose beta or stable streams, etc.
> For example, the Google Play app store, you can check a box to opt in
> to beta versions of an app you're interested in following the bleeding
> edge of. It'd be awesome to do that in Fedora. We *could* do that with
> traditional packaging, but in practice doing it well seems like at
> least as much work as the flatpak bundle approach — and we still
> wouldn't get the update advantage.
Opt-in:
su - (or sudo -i)
dnf copr enable myapp-beta
dnf distro-sync
Opt back out and roll back:
su - (or sudo -i)
dnf copr disable myapp-beta
dnf distro-sync
Where's the problem? This is also trivial to offer in a UI.
What if upgrading to myapp-beta requires upgrading also e.g. to a major
version of Qt (or any other widely used library that has some potential
to either have regressions or even just be incompatible between
versions) that is more recent than what my Fedora installation ships? If
distro-sync proposes any upgrades beyond the one thing that the user
really wants to upgrade, how will any non-technical user be able to tell
if this will destabilise something else?
With flatpak and other comparable tools, the application can set up to
use a more recent runtime while the existing applications are left
untouched. Even for a user who gets all their software from Fedora, I'd
expect it to be possible for a user of stable Fedora N to pick any of
the application versions available in Fedora (N-1), (N+1) and rawhide.
At least I have so far pretty much avoided all COPR use because I wish
to spend time on something else than judging this. I have some
applications installed through flatpak and there it is nice to know that
the installations do not affect how the programs that I get from Fedora
work.
- Joonas
9:10 a.m.
On Sun, Jul 16, 2017 at 01:29:01PM +0200, Kevin Kofler wrote:
umbrella? It may as well come directly from upstream at that point.
The
whole point of delivering software under the Fedora umbrella is to deliver
it as RPMs. If there is no RPM, delivering through Fedora is completely
useless.
I strongly dispute the idea that Fedora must be tied to a particular
packaging technology.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:51 a.m.
Kevin Kofler kirjoitti 16.07.2017 klo 15:10:
Debarshi Ray wrote:
> How about reliable online updates of running applications as a
> benefit?
Upgrading RPM applications online just works. I do it all the time. The KDE
tools do not even implement offline updates (and IMHO that's a good thing).
I
think this is a bit funny because in my experience, especially KDE
software tends to get disrupted by upgrading that software while it is
running.
Just to check if my experience is still up to date, I made a fresh
Fedora 25 KDE installation into a VM, booted it up and logged in. Then
in the Plasma desktop session I updated the system through the
notification that tells me that there's 900+ updates available. Found
these anomalies on the first try:
- Dolphin complains about some crashed process when I open the Network place
- Plasmashell crashed and got automatically restarted mid-upgrade.
- Ksysguard stopped displaying both of its default tabs (it still shows
the one that I added for monitoring disk throughput)
- Dolphin crashed after I browsed around in it after completing the upgrade
- In Gwenview, the "open file" chooser fails to show any files. Instead
it complains about a crashed backend process.
I would be much happier to use Fedora KDE if its shutdown menu had a
similar "reboot to upgrade and shut down" option that Fedora Workstation
provides. I still do usually upgrade with dnf, though, because Gnome
seems a bit less likely to encounter these issues.
I know that normally I would not do the first upgrade after installation
this way, but this was a fairly sure way for me to find something
concrete to point at.
The worst that can happen is that some recalcitrant applications (by
far the
minority) need to be restarted after updating (or if you upgraded the whole
desktop, then your session may need to be restarted after updating). Until
you do that, the current session may be "hosed" to some extent, but
restarting will fix it. It is surely the lesser evil than forcing a complete
system reboot before the update as GNOME does now. I never had a hosed
system. In most cases, I just run the updates and continue working without
even restarting anything, it just works.
I have been doing that same thing but I
really do not like that I kind
of do not know what I will get. Usually indeed nothing special happens,
but then sometimes I have had
This issue is being deeply blown out of proportion.
You certainly can live with the
occasional weirdness that can happen
when a you do a traditional dnf update or some other comparable software
upgrade operation. But this problem has been there for many years
already and it is not just KDE where upgrade-while-in-use is badly
supported. Many major applications do not seem likely to start handing
this better in foreseeable future. I think it is just good that Fedora
is getting some ways to upgrade applications where applications do not
get exposed to a situation where their files get replaced mid-flight.
Then an user who just follows directions presented by Fedora will not
encounter the kind of anomalies that I listed above.
- Joonas
11:50 a.m.
On Sun, Jul 16, 2017 at 9:21 AM, Christian Dersch <lupinix(a)mailbox.org> wrote:
I hope we will *never* reach that point, if we reach it, I have to
move
to another Linux distribution which follows the rules of construction I
prefer. As a packager I know how much many upstreams love bundling (and
not updating bundled libs), IMHO Flatpak (in general) encourages them to
do that (yes I know, they can do also for RPM, but Flatpak makes it
easy). And outdated libraries are a high security risk (heartbleed etc.
;)) and sandboxing can never save you from all possible impacts.
Sandboxing is an *additional* and as said in some other mail
*orthogonal* mechanism to clean packaging. I feel we lose many
advantages over operating systems like Windows if we open that door and
continue that way…
[snip]
That said, for the optional availability of flatpak for packagers:
I'm
perfectly fine with that, I'll just ignore it for my stuff. But if there
will be proposals which will change Fedora in a way that I think is
wrong, I'll be back to discuss them ;) Also I know from IRC that there
are more packagers thinking the same way.
I'm definitely such a packager, so I figured I'd chime in and add my
voice here. I agree completely.
Six years or so ago, I installed a Linux distribution-- Fedora, as it
happens-- for the first time, and was very quickly sold on the package
management model as a method to distribute software. I became a Fedora
packager because it seemed so self-evident to me that it was a better
way to distribute software than either the Windows model or the
smartphone application store model. These days I primarily use Fedora
and only occasionally boot into Windows, and one of the things that
helped more or less fully convert me to Linux was traditional package
management.
As an end-user, the only way I'd find the flatpakization of Fedora
acceptable is if I could still do "[package manager] install firefox;
firefox [options]" and have it launch Firefox, regardless as to how
Firefox was packaged. (As an aside, I suspect a *lot* of people are
going to complain if this sort of thing doesn't work if/when Firefox
is turned into a flatpak). If so, I might consider continuing to *use*
the distribution. But as a packager, I'm just not convinced the
potential benefits of sandboxing are worth it, and would have to
seriously consider whether I'm still interested in contributing to
Fedora, if this were to happen.
I can't presume to speak for anyone else, but it wouldn't surprise me
to learn that there are other contributors who feel similarly-- who
chose to contribute because they liked traditional package management
and are now uncomfortable at the idea of replacing it.
All that being said:
I don't have any problem with Fedora growing the technology to build
flatpaks and other packaging formats, as it already has for those who
want to distribute and ship them. I think that there's nothing wrong
with Fedora offering up a choice of images composed using technologies
such as Atomic, flatpak, docker, and so on, for people with different
usage cases. And I don't use Fedora Workstation, so if GNOME Software
wants to advertise flatpaks over RPMs, that doesn't particularly
bother me. So I have no issue with this particular change. But I felt
like I should chime in here because this change thread has turned (as
any discussion on flatpak seems to) into a general discussion on the
future of packaging technology, and I've been uneasy for about a year
now about the direction Fedora might go here.
Ben Rosser
12:17 p.m.
On 16 July 2017 at 10:10, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Sun, Jul 16, 2017 at 01:29:01PM +0200, Kevin Kofler wrote:
> umbrella? It may as well come directly from upstream at that point. The
> whole point of delivering software under the Fedora umbrella is to deliver
> it as RPMs. If there is no RPM, delivering through Fedora is completely
> useless.
I strongly dispute the idea that Fedora must be tied to a particular
packaging technology.
I am going to agree with Kevin on this from clasical brand management
point of view. Fedora Linux sits on a 20+ year lifetime of being an
RPM based Linux Operating System. If you ask people about Fedora both
inside and outside about the community what is Fedora, they are going
to call it an RPM based Linux technology much more likely than they
will think about the Four Foundations or anything else. People have
chosen or rejected Fedora for years over RPM vs Deb or Pacman or
anything else. RPM is part and parcel of what makes Fedora for most
people.
To put this in a similar real life analogy... someone says Harley
Davidson, you think motorcycle with a specific oversized engine. At
one point they looked at trying to break into some lighter motorcycle
markets and also the car market. The problem was that a) potential
customers could not envision a small Harley or a car Harley and b)
existing customers felt the company was selling out. And when Harley
has made such vehicles, they never get into the market beyond a "here
is our token light motorcycle".
Now it isn't impossible to change images, but it is going to be a long
slow ride. We aren't talking ocean liner or container ship turning
radius. We are talking giant iceberg turning radius because most of
the identity is deep down inside where you can't see it. It is going
to break up the iceberg into various bits and it is going to be messy
and painful. It isn't something that can be done in 2-3 releases
because we aren't talking code, we are talking about deep rooted human
clan identity. [The fact that I am agreeing with Kevin Kofler should
be a signal.]
These sorts of deep brand issues are why most companies start new
brands which might look like they are competing with their primary
one. It can showcase some new identity and get people to see it as
useful or better than what they have already. It can also show where
things aren't going to work at all because people just aren't
interested in something. The Soap industry is a classic study in
brands where most people buy things because of something they tie to
the brand be it a logo, a smell, a look or even just the container it
comes in. Whenever the company changes those things, it causes
significant drop in sales and they are usually going back to what they
had. So instead a soap company will just start a new line with
whatever is different they want to see. No tie in with the original
soap. Sometimes that soap takes over and other times it just sits
there and goes away after 8 months.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
1:54 p.m.
On 16 July 2017 at 13:11, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Where's the problem?
The problem is it simply does not work on anything nontrivial that
needs an updated library dep of something already in Fedora. On your
stable system running F25, can you try installing a few new versions
of upstream-active applications in F27 that requires the new QT or
GTK? Before you know it your super-stable production system is a huge
mix of incompatible packages, which is unrecoverable. Downgrades are
not supported officially, and they're simply not something that is
tested. If it works, it's more by accident than design.
Flatpak lets me have multiple versions of apps installed, depending on
specific versions of base libraries. We can actually test an
application always works using a known set of libraries, rather than
the application exploding because it's not doing runtime checks for
subtle changes in library behaviour.
This is also trivial to offer in a UI.
I think you and I disagree on what trivial constitutes.
And the (unrelated) online update issue is really a non-issue in
practice,
as I explained in my reply to Debarshi Ray.
Until you're the person that's explaining to someone why their system
is HOSED (hint: that's usually me) because they rebooted during a live
update, please don't call this a non-issue. Moving to offline updates
reduced the number of people filing bugs about systems being broken by
about two orders of magnitude. "But it always worked fine for me"
doesn't scale to tens of millions of users.
Packages are a great way to build a system (either ostree or flatpak,
or both), but I think the last 15 years of experience shows us it's
not a great way to manage a system. Nobody is taking away packages. If
you want to use packages, fine, please don't prevent us doing new,
better things.
Richard
2:07 p.m.
On Fri, Jul 14, 2017 at 09:29:29PM +0200, Lars Seipel wrote:
On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanzaro(a)gnome.org
wrote:
> But we have not been. Very few applications actually have SELinux profiles,
> and they are all maintained downstream rather than upstream. The volume of
> erroneous SELinux denials in Bugzilla is too high, and the response time for
> fixing them too slow. SELinux profiles work best when they are maintained
> upstream by application developers who are familiar with SELinux, not by
> SELinux developers who are unfamiliar with the application.
We do have the same issue with sandbox policies for Flatpak, no?
No, IMHO. The approach of SELinux vs. "namespace+seccomp jail" (let's call
that what flapak as well as systemd does) is realized at a different level.
First SELinux policy is a global policy that ties the labelling of all
files, all process, and all users, so it must be maintained centrally.
Second, the area of exposure is enormous, because SELinux must decide the
interaction between any process and any file type, at the level of
individual syscalls. That's why we are always playing catch-up with
the policy.
With the "namespace+seccomp jail" approach, one starts with a very
limited view of the file system, with large swaths of it additionally
read-only/nodev/noexec. On top of that specific "things" are made
visible, on a much higher level. So the policy is decentralized
(the sandbox makes specific mechanisms possible, but the application
packagers decide the details of the policy), and written at a
higher level. I expect that once the implementations of various
"portals" have matured, wring flatpak policy will be quite easy.
(You can see the same with systemd units: some have quite restrictive
policy, including seccomp filters and strong filesystem visibility
limitations, yet this doesn't seem to be causing frequent issues.)
Zbyszek
> This
> is the hard part of any sandboxing system and (judging from the current
> docs) Flatpak hasn't tackled it yet.
>
> A Flatpak app currently requires the following incantation to access the
> host's dconf, so that it can behave like its users would expect:
>
> > --filesystem=xdg-run/dconf
> > --filesystem=~/.config/dconf:ro
> > --talk-name=ca.desrt.dconf
> > --env=DCONF_USER_CONFIG_DIR=.config/dconf
>
> Now, while this specific dconf issue might get solved at some point,
> dconf won't be enough for the vast majority of useful apps. All the crap
> that lives in the various dot files in your home directory and elsewhere
> on the system and that affects the behaviour of a program needs to be
> made available to the app. Other things must not be, such as everything
> containing secrets.
>
> Some apps (e.g. virt-manager) need access to your ssh-agent socket but
> you certainly don't want to make it available to every single app. This
> is just a single instance of the general case of a program talking to
> one of the numerous services that may run on the host.
> programs depending on user configuration.
>
> You want some environment variables passed through to the sandboxed app
> (EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the
> Flatpak app even going to execute your favorite editor?
>
> Someone is going to have to write all the policy for that. Otherwise,
> the only apps that Flatpak will be able to handle properly are going to
> be trivial mobile-style apps that don't interact with anything but their
> developer's cloud services.
2:32 p.m.
On 07/16/2017 08:54 PM, Richard Hughes wrote:
> This is also trivial to offer in a UI.
I think you and I disagree on what trivial constitutes.
> And the (unrelated) online update issue is really a non-issue in practice,
> as I explained in my reply to Debarshi Ray.
Until you're the person that's explaining to someone why their system
is HOSED (hint: that's usually me) because they rebooted during a live
update, please don't call this a non-issue. Moving to offline updates
reduced the number of people filing bugs about systems being broken by
about two orders of magnitude. "But it always worked fine for me"
doesn't scale to tens of millions of users.
I doubt "two orders of magnitude" as I run the desktop machines at
university department even with dnf-automatic without high impact.
Sometimes a reboot might be required or useful, but that does not
prevent successful live updates. Also offline updates have their own
disadvantages, as the process can take long time depending on the
updates (worst case: texlive), this is really annoying. You think "Oh,
some updates, apply them before I start to work" and then have to wait
long time. The only thing that has to be ensured: No shutdown or reboot
while update is running. But this does not justify offline updates. One
thing that would be nice to have (and not so hard to implement), a flag
whether logout or reboot is suggested after update is done (the info we
have in bodhi). If flag raised, dnf can print message @terminal and/or
use notification daemon for that.
Packages are a great way to build a system (either ostree or
flatpak,
or both), but I think the last 15 years of experience shows us it's
not a great way to manage a system.
I completely disagree here, packages have
proven to be a great way here
within last decades, even in enterprise field ;) I see use cases for
ostree and especially for this discussion: flatpak, therefore we should
provide the runtime and also SDK to build, of course. But I really don't
get the point of using it as a general distribution mechanism. There
packages are just fine (and IMHO preferred as the more low level way)
and the Fedora distribution itself has to be self-consistent anyway, no
matter what we use. But packages are the established way, no need to change.
Greetings,
Christian
3:14 p.m.
Joonas Sarajärvi wrote:
What if upgrading to myapp-beta requires upgrading also e.g. to a
major
version of Qt (or any other widely used library that has some potential
to either have regressions or even just be incompatible between
versions) that is more recent than what my Fedora installation ships? If
distro-sync proposes any upgrades beyond the one thing that the user
really wants to upgrade, how will any non-technical user be able to tell
if this will destabilise something else?
Fedora normally already offers the latest version of Qt in the stable
updates. (Qt 5.9.x updates for Fedora 25 and 26 are coming soon.) Qt is
fully backwards compatible, so upgrading it is normally not an issue. And
really MAJOR new versions of Qt, e.g. 4 vs. 5, are fully parallel-
installable.
And this is the model that should be followed for other libraries with the
same type of branching strategy as well. Just upgrade the system version.
Now, if the system version of a library is too old, the Copr can simply
offer a newer version. That (and also automatic updates, of course) is what
Copr is for, as opposed to just pointing to a single RPM. And of course,
disabling the Copr and doing a distro-sync will also revert those libraries.
With flatpak and other comparable tools, the application can set up
to
use a more recent runtime while the existing applications are left
untouched. Even for a user who gets all their software from Fedora, I'd
expect it to be possible for a user of stable Fedora N to pick any of
the application versions available in Fedora (N-1), (N+1) and rawhide.
I do not consider this a realistic expectation, at all.
At least I have so far pretty much avoided all COPR use because I
wish
to spend time on something else than judging this. I have some
applications installed through flatpak and there it is nice to know that
the installations do not affect how the programs that I get from Fedora
work.
And I would pick a Copr over a Flatpak any day. I used and use several Copr
repositories, they are much nicer than some unpackaged blob. And getting rid
of them later is fairly easy.
Kevin Kofler
3:43 p.m.
Richard Hughes wrote:
The problem is it simply does not work on anything nontrivial that
needs an updated library dep of something already in Fedora. On your
stable system running F25, can you try installing a few new versions
of upstream-active applications in F27 that requires the new QT or
GTK? Before you know it your super-stable production system is a huge
mix of incompatible packages,
Qt is normally upgraded in stable releases. Qt 5.9 is being prepared for F25
and F26. The upgrades mostly just work (Qt is fully backwards-compatible),
only the packages using private APIs (clearly tagged as such) need to be
rebuilt (the rebuilds are included with the updates upgrading Qt).
In addition, Qt applications often do not require the very latest Qt. E.g.,
the latest stable QupZilla still builds against Qt 5.7. Many upstream
projects even still support Qt 5.6.
which is unrecoverable. Downgrades are not supported officially, and
they're simply not something that is tested. If it works, it's more by
accident than design.
Your PackageKit does not support downgrades, but DNF does.
Flatpak lets me have multiple versions of apps installed, depending
on
specific versions of base libraries. We can actually test an
application always works using a known set of libraries, rather than
the application exploding because it's not doing runtime checks for
subtle changes in library behaviour.
This comes at a huge cost in space for duplicated libraries, a price that I
am not willing to pay.
> This is also trivial to offer in a UI.
I think you and I disagree on what trivial constitutes.
A Copr enabler GUI is very simple: just bring up a dialog box with a
checkbox list of Coprs (the checkbox enables or disables the Copr) and an
Apply button that does a distro-sync.
Until you're the person that's explaining to someone why
their system
is HOSED (hint: that's usually me) because they rebooted during a live
update, please don't call this a non-issue. Moving to offline updates
reduced the number of people filing bugs about systems being broken by
about two orders of magnitude. "But it always worked fine for me"
doesn't scale to tens of millions of users.
Rebooting during an update is a completely unrelated issue from the one that
was described. It will also break things if you do it during an offline
update.
And besides, systemd will not even allow you to shutdown or reboot during a
PackageKit update. (I accidentally tried to shutdown my notebook before my
plasma-pk-updates update was 100% complete lately, it just refused to shut
down and completed the update instead.) If you just cut the power, then you
deserve what you get.
Packages are a great way to build a system (either ostree or
flatpak,
or both), but I think the last 15 years of experience shows us it's
not a great way to manage a system.
Yet I have been using packages to manage my system just fine during those 15
years, it works much better than the alternatives.
Nobody is taking away packages. If you want to use packages, fine,
please
don't prevent us doing new, better things.
Really? Then why is Owen talking about allowing or even requiring GUI
applications to be Flatpak only? Don't take my RPMs away!
Kevin Kofler
4:08 p.m.
Joonas Sarajärvi wrote:
Just to check if my experience is still up to date, I made a fresh
Fedora 25 KDE installation into a VM, booted it up and logged in. Then
in the Plasma desktop session I updated the system through the
notification that tells me that there's 900+ updates available. Found
these anomalies on the first try:
- Dolphin complains about some crashed process when I open the Network
place
- Plasmashell crashed and got automatically restarted mid-upgrade.
- Ksysguard stopped displaying both of its default tabs (it still shows
the one that I added for monitoring disk throughput)
- Dolphin crashed after I browsed around in it after completing the
upgrade
- In Gwenview, the "open file" chooser fails to show any files. Instead
it complains about a crashed backend process.
That's what I meant with "upgrading the whole desktop". Just restart your
session when the upgrade is done, no harm done. This kind of a mess does not
happen with routine updates.
Kevin KOfler
4:13 p.m.
Matthew Miller wrote:
I strongly dispute the idea that Fedora must be tied to a particular
packaging technology.
The particular packaging technology is what ensures that we have a coherent,
integrated system. Flatpaks by design cannot offer the kind of integration
that native packages can offer, neither in terms of using shared system
libraries (saving space), nor in terms of user experience (even with
"portals", there will always be kinds of interoperation that the sandbox
just cannot allow).
And if the users will get their packages in a generic format rather than a
native Fedora format, what advantage do they get from getting it from Fedora
to begin with? The point of delivering Fedora packages is to integrate them
into the distribution. Only native packages can provide that.
Fedora could deliver a similar experience using a different packaging
format, such as deb (but why would we throw away what we have with RPM
then?), but not with a container format such as Flatpak.
Kevin Kofler
4:47 p.m.
On Sun, 16 Jul 2017 13:17:25 -0400
Stephen John Smoogen <smooge(a)gmail.com> wrote:
These sorts of deep brand issues are why most companies start new
brands which might look like they are competing with their primary
one. It can showcase some new identity and get people to see it as
useful or better than what they have already. It can also show where
things aren't going to work at all because people just aren't
interested in something. The Soap industry is a classic study in
brands where most people buy things because of something they tie to
the brand be it a logo, a smell, a look or even just the container it
comes in. Whenever the company changes those things, it causes
significant drop in sales and they are usually going back to what they
had. So instead a soap company will just start a new line with
whatever is different they want to see. No tie in with the original
soap. Sometimes that soap takes over and other times it just sits
there and goes away after 8 months.
+1
7:56 p.m.
Hi,
On Fri, Jul 14, 2017, at 05:52 PM, Andrew Lutomirski wrote:
I don't see the problem. The runtime could be all of /use and
the app
could be a symlink living in /app that points at /usr. The latter
could be created on the fly in a tmpfs.
You're right; however, there are two other aspects to this.
First, RPMs (as we use them) are designed for a single merged /usr,
and their %post scripts run with full CAP_SYS_ADMIN privileges.
This means if one wants to install any 3rd party apps, any sandboxing
at runtime is...well, useful, but there's a rather gaping hole if the
app is malicious, or the app provider is compromised. This argument
also applies to distributions I think as well - it will improve security
to ensure that many apps and shared libraries (that aren't used in
host systems) *never* have CAP_SYS_ADMIN.
Second, to rephrase Richard's reply, the code+process lifecycle
binding is significantly simplifed in the flatpak model. It by
default implements a model where updates don't delete files
underneath running apps. This has never (AFAIK) been solved in the traditional package
manager model, and though I could imagine doing so, you'd
really end up with separate filesystem trees, whether those are
explicit or implicit.
9:52 p.m.
On Sun, Jul 16, 2017 at 3:14 PM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
And I would pick a Copr over a Flatpak any day. I used and use
several Copr
repositories, they are much nicer than some unpackaged blob. And
getting rid
of them later is fairly easy.
Although you have some valid concerns about Flatpak, I think it's a big
mistake to promote Copr. Copr has worked out well enough for us so far
only because we use it on a very small scale. If there were many
popular Copr repos, they would quickly conflict with each other and it
would become a nightmare to use them. And conflicts will horribly break
users' systems. This isn't a theoretical problem, we know it's what
will happen because openSUSE already has many popular Coprs, they just
call it something different (OBS). Users bork their machines all the
time by enabling conflicting repos to install different packages. It's
a big problem.
Coprs are fine and safe so long as they are just carrying new versions
of applications and not replacing any system packages. In fact, we have
policy in Fedora Workstation that Coprs that follow these rules can
even be enabled by default, out-of-the-box. (We already have one or
two, though I don't remember what they are and it only works if you use
GNOME Software.) But frequently, the only way to ship a new version of
an application in a Copr is to also upgrade its dependencies, and there
you're getting into extremely dangerous territory. We can't have that.
Flatpak solves this problem.
Michael
P.S. On a completely unrelated note... and just brainstorming... so
long as our Flatpaks are built from RPMs, there's probably no great
technical reason to get rid of the RPMs, even if Flatpak becomes the
primary/default distribution mechanism. We mainly just need a way to
avoid confusion when reporting bugs, since the RPM and Flatpak versions
of applications could have different bugs.
9:56 p.m.
On Sun, Jul 16, 2017 at 3:43 PM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
If you just cut the power, then you deserve what you get.
You and I are both fortunate that power cuts are rare where we live.
But one happened to me a couple of days ago during a 'git pull', and I
lost the git repo. It would have been much more frustrating if I had
been doing a dnf update and lost my RPM database... at that point, you
pretty much have to reinstall.
I think our offline updates are actually still vulnerable to the same
issue, because they are not transactional yet (maybe unless you have
btrfs?). But they are a necessary step to fix this problem.
Michael
2:33 a.m.
On su, 16 heinä 2017, Kevin Kofler wrote:
Joonas Sarajärvi wrote:
> Just to check if my experience is still up to date, I made a fresh
> Fedora 25 KDE installation into a VM, booted it up and logged in. Then
> in the Plasma desktop session I updated the system through the
> notification that tells me that there's 900+ updates available. Found
> these anomalies on the first try:
>
> - Dolphin complains about some crashed process when I open the Network
> place
> - Plasmashell crashed and got automatically restarted mid-upgrade.
> - Ksysguard stopped displaying both of its default tabs (it still shows
> the one that I added for monitoring disk throughput)
> - Dolphin crashed after I browsed around in it after completing the
> upgrade
> - In Gwenview, the "open file" chooser fails to show any files. Instead
> it complains about a crashed backend process.
That's what I meant with "upgrading the whole desktop". Just restart your
session when the upgrade is done, no harm done. This kind of a mess does not
happen with routine updates.
Konversation gets routinely killed every time dbus
daemon reloads its
configuration or restarts during updates. This is not even remotely
funny.
--
/ Alexander Bokovoy
3:35 a.m.
Colin Walters wrote:
First, RPMs (as we use them) are designed for a single merged /usr,
and their %post scripts run with full CAP_SYS_ADMIN privileges.
This means if one wants to install any 3rd party apps, any sandboxing
at runtime is...well, useful, but there's a rather gaping hole if the
app is malicious, or the app provider is compromised. This argument
also applies to distributions I think as well - it will improve security
to ensure that many apps and shared libraries (that aren't used in
host systems) *never* have CAP_SYS_ADMIN.
Second, to rephrase Richard's reply, the code+process lifecycle
binding is significantly simplifed in the flatpak model. It by
default implements a model where updates don't delete files
underneath running apps. This has never (AFAIK) been solved in the
traditional package manager model, and though I could imagine doing so,
you'd really end up with separate filesystem trees, whether those are
explicit or implicit.
But both these points are not worth throwing away the efficiency of shared
dependencies!
Kevin Kofler
3:38 a.m.
Michael Catanzaro wrote:
P.S. On a completely unrelated note... and just brainstorming... so
long as our Flatpaks are built from RPMs, there's probably no great
technical reason to get rid of the RPMs, even if Flatpak becomes the
primary/default distribution mechanism. We mainly just need a way to
avoid confusion when reporting bugs, since the RPM and Flatpak versions
of applications could have different bugs.
The problem is that the RPMs that go into the Flatpaks are not FHS-
compliant, so the RPMs will have to carry some conditionals and be built
twice.
Kevin Kofler
3:43 a.m.
On Sun, Jul 16, 2017 at 01:29:01PM +0200, Kevin Kofler wrote:
Daniel P. Berrange wrote:
> If I look at this from my POV as the upstream maintainer of a graphical
> application wishing to make it widely available to users of many distros.
> The question is whether it is beneficial for me to join Fedora packaging
> world to package my app, or whether to package it standalone as a flatpak
> and never get involved in Fedora at all.
>
> With the proposed F27 rule here, I would have less work todo if I just
> built my app as a flatpak, as I can avoid creating RPMs and just build
> a single flatpak that should work on all distros. IOW by mandating
> continued creation of RPMs, alongside flatpaks, we would be discouraging
> people from becoming Fedora maintainers.
From a user standpoint, what's the difference? What's the benefit from
having upstream deliver their software Flatpak-only under the Fedora
umbrella? It may as well come directly from upstream at that point. The
whole point of delivering software under the Fedora umbrella is to deliver
it as RPMs. If there is no RPM, delivering through Fedora is completely
useless.
Use of RPM is merely a particular historical choice of delivery mechanism,
and certainly not the defining characteristic of what it means to be the
Fedora distribution. For users consuming the Fedora desktop, the fact that
they're using RPM is hidden away as an implementation detail behind the
apps like GNOME software.
Upstream still has to choose what base layer(s) they build their application
flatpak on top of, and thus Fedora is a clearly choice there. Fedora also
still provides the infrastructure for building flatpaks, hosting to distribute
and mirror them, review of flatpak image manifests, quality testing before
release, and more. Essentially the things that Fedora already does for
software provided via RPMs, are still beneficial to at least some extent
when using flatpaks.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:48 a.m.
On Sat, Jul 15, 2017 at 05:17:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > 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.
>
> If I look at this from my POV as the upstream maintainer of a graphical
> application wishing to make it widely available to users of many distros.
> The question is whether it is beneficial for me to join Fedora packaging
> world to package my app, or whether to package it standalone as a flatpak
> and never get involved in Fedora at all.
>
> With the proposed F27 rule here, I would have less work todo if I just
> built my app as a flatpak, as I can avoid creating RPMs and just build
> a single flatpak that should work on all distros. IOW by mandating
> continued creation of RPMs, alongside flatpaks, we would be discouraging
> people from becoming Fedora maintainers.
>
> Thus could suggest more flexibility - require continued maint of RPMs
> for *existing* applications in Fedora only, to give some grace period
> where we figure out how to provide a seemless upgrade path for people
> who have an existing RPM installed to magically replace it with flatpak.
> Anyone wishing to package a *new* application in F27, however, should be
> able to straight to flatpaks only as there's no upgrade path issue to
> worry about.
>
> This would encourage upstream app maintainers to join Fedora to make
> use of the review, build & distribution mechanisms for flatpaks, without
> forcing them todo extra work to create RPMs too.
This depends on how exactly flatpacks are built:
- if first an rpm is built, and then flatpack is built out of rpms,
it's strictly more work (although there are benefits to users of installing
using flatpacks over plain rpms, so it's an actual benefit for users
and hence not pointless).
- if one is building a _leaf_ application, and all deps are available as
rpms, then the packager doesn't need to follow the strict rpm rules,
and if they only build a flatpack without the intermediate rpm,
some work is saved.
- if one is building an application that anything else depends on, things
get more complicated.
(Let's take inkscape as an example: it's a end-user graphical application,
but it has command-line mode where it converts svgs to pngs and such,
so it might be used e.g. when generating documentation or in %check
for another package.)
If inkscape is still available as rpm, it can be used as a dep in building
other rpms. If however inkscape suddenly becomes available only as a flatpack,
how does that work? Do we allow rpms to specify BuildRequires: inkscape.flatpack,
and koji will install it and make the application available?
Even if technically possible in the future, I don't think it's
something we'd want to commit to right now.
Yeah, that last point is the real difficult issue, it forces you to keep
the RPM in parallel with the flatpak, unless we were to either change
RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
to pull in it contents.
So in the end, flatpacks as an *additional* distribution mechanism
sound fine. But if they become the *only* distribution mechanism, we
risk that the whole ecosystem of packages which can all be used to
build one another falls apart.
I guess one key question is how often the Inkscape situation arises where
a graphical application can be considered both a leaf node, and a dependancy
for other arbitrary app.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:03 a.m.
On 16.07.2017 12:54, Richard W.M. Jones wrote:
On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>
>> If RPMs of the graphical application work fine now, what on earth is
>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
>> of them - as already explained, sandboxing is orthogonal to packaging.
>
> Huh? How would you get sandboxing without Flatpaks? Unless you are
> proposing a different sandboxing technology.
Things like libvirt-sandbox have been around for a really long time
and don't require special packaging (in fact they work with any
arbitrary command).
reading between the lines of the fine documentation, there is no mention
of X11 or GUI applications, so i guess "arbitrary" is a bit of an
exaggeration?
http://sandbox.libvirt.org/quickstart/
http://sandbox.libvirt.org/faq/
5:16 a.m.
It's like you didn't listen to the arguments when this feature was implemented in
Fedora years ago, and continue not to.
You're wrong, and the fact that you keep insisting you're not is frankly
intellectual dishonesty.
If you really believe you're correct, try to kill your X server in the middle of an
upgrade... Or simply re-read the tons of examples in the old threads.
----- Original Message -----
> Debarshi Ray wrote:
> > How about reliable online updates of running applications as a
> > benefit?
>
> Upgrading RPM applications online just works. I do it all the time. The KDE
> tools do not even implement offline updates (and IMHO that's a good thing).
> The worst that can happen is that some recalcitrant applications (by far the
> minority) need to be restarted after updating (or if you upgraded the whole
> desktop, then your session may need to be restarted after updating). Until
> you do that, the current session may be "hosed" to some extent, but
> restarting will fix it. It is surely the lesser evil than forcing a complete
> system reboot before the update as GNOME does now. I never had a hosed
> system. In most cases, I just run the updates and continue working without
> even restarting anything, it just works.
>
> This issue is being deeply blown out of proportion.
>
> Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
5:45 a.m.
On 16.07.2017 14:10, Kevin Kofler wrote:
Debarshi Ray wrote:
> How about reliable online updates of running applications as a
> benefit?
Upgrading RPM applications online just works. I do it all the time. The KDE
tools do not even implement offline updates (and IMHO that's a good thing).
The worst that can happen is that some recalcitrant applications (by far the
minority) need to be restarted after updating (or if you upgraded the whole
desktop, then your session may need to be restarted after updating). Until
you do that, the current session may be "hosed" to some extent, but
restarting will fix it.
no, the worst case is this:
https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-whe...
5:53 a.m.
On Mon, Jul 17, 2017 at 12:45:27PM +0200, Michael Stahl wrote:
On 16.07.2017 14:10, Kevin Kofler wrote:
> Debarshi Ray wrote:
>> How about reliable online updates of running applications as a
>> benefit?
>
> Upgrading RPM applications online just works. I do it all the time. The KDE
> tools do not even implement offline updates (and IMHO that's a good thing).
> The worst that can happen is that some recalcitrant applications (by far the
> minority) need to be restarted after updating (or if you upgraded the whole
> desktop, then your session may need to be restarted after updating). Until
> you do that, the current session may be "hosed" to some extent, but
> restarting will fix it.
no, the worst case is this:
https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-whe...
I had this kind of fun problem upgrading F25 -> F26. I was lazy and didn't
want to reboot so I was just running dnf distro-sync in a gnome-terminal
session. I've upgrade this way since F6 and mostly it just works, but
forgot to nohup it. About 1/3 of the way through installing new packages,
something causes gnome-terminal to die. I had to write a script to read
the dnf planned transaction log and finish installing and erasing remaining
packages, and manually run any %posttrans scripts.
So yeah, even with latest Fedora things can & do go horribly wrong if you
ignore the advice to not run upgrades from a live system.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:32 a.m.
On Monday, July 17, 2017 11:53:35 Daniel P. Berrange wrote:
I had this kind of fun problem upgrading F25 -> F26. I was lazy
and didn't
want to reboot so I was just running dnf distro-sync in a gnome-terminal
session. I've upgrade this way since F6 and mostly it just works, but
forgot to nohup it. About 1/3 of the way through installing new packages,
something causes gnome-terminal to die. I had to write a script to read
the dnf planned transaction log and finish installing and erasing remaining
packages, and manually run any %posttrans scripts.
So yeah, even with latest Fedora things can & do go horribly wrong if you
ignore the advice to not run upgrades from a live system.
How are you confirming that it was update of a graphical application that
broke your gnome-terminal and consequently the whole update process?
I would rather expect update of dbus, systemd and the like to cause such
troubles. In that case, Flatpaks could hardly improve the situation...
Kamil
7 a.m.
On Mon, Jul 17, 2017 at 6:53 AM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
On Mon, Jul 17, 2017 at 12:45:27PM +0200, Michael Stahl wrote:
> On 16.07.2017 14:10, Kevin Kofler wrote:
> > Debarshi Ray wrote:
> >> How about reliable online updates of running applications as a
> >> benefit?
> >
> > Upgrading RPM applications online just works. I do it all the time. The KDE
> > tools do not even implement offline updates (and IMHO that's a good thing).
> > The worst that can happen is that some recalcitrant applications (by far the
> > minority) need to be restarted after updating (or if you upgraded the whole
> > desktop, then your session may need to be restarted after updating). Until
> > you do that, the current session may be "hosed" to some extent, but
> > restarting will fix it.
>
> no, the worst case is this:
>
>
https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-whe...
I had this kind of fun problem upgrading F25 -> F26. I was lazy and didn't
want to reboot so I was just running dnf distro-sync in a gnome-terminal
session. I've upgrade this way since F6 and mostly it just works, but
forgot to nohup it. About 1/3 of the way through installing new packages,
something causes gnome-terminal to die. I had to write a script to read
the dnf planned transaction log and finish installing and erasing remaining
packages, and manually run any %posttrans scripts.
So yeah, even with latest Fedora things can & do go horribly wrong if you
ignore the advice to not run upgrades from a live system.
This happens because DNF doesn't spawn a process in the background to
do this. When you use dnfdragora or a PackageKit frontend, you get
that benefit, because the actual transaction isn't being done by the
user interface process.
In the case of dnfdragora, the dnfdaemon handles it. In the case of
things like GNOME Software, Plasma Discover, etc., the PackageKit
daemon handles it.
A relatively simple enhancement would be to have DNF self-daemonize
when it does transactions through the CLI, so that issues like that
don't happen.
--
真実はいつも一つ！/ Always, there's only one truth!
8:16 a.m.
On Sun, Jul 16, 2017 at 11:56:26AM +0100, Richard W.M. Jones wrote:
On Fri, Jul 14, 2017 at 10:04:37PM +0100, Richard Hughes wrote:
> On 14 July 2017 at 20:28, Andreas Tunek <andreas.tunek(a)gmail.com> wrote:
> > Is this really more reliable than using dnf (for graphical packages
> > like Recepies and Builder)?
>
> It's hugely more reliable. You can't actually trust rpm to do anything
> atomically,
Which could be fixed and the fix would benefit everyone ...
> and this is the main reason we force upgrade to be offline
> in the workstation product.
No, that's a workaround for not fixing it properly.
No, that's not true.
(I love one-liners.)
9:10 a.m.
On Sun, Jul 16, 2017 at 01:17:25PM -0400, Stephen John Smoogen wrote:
These sorts of deep brand issues are why most companies start new
brands which might look like they are competing with their primary
one. It can showcase some new identity and get people to see it as
useful or better than what they have already. It can also show where
things aren't going to work at all because people just aren't
interested in something. The Soap industry is a classic study in
brands where most people buy things because of something they tie to
the brand be it a logo, a smell, a look or even just the container it
comes in. Whenever the company changes those things, it causes
significant drop in sales and they are usually going back to what they
had. So instead a soap company will just start a new line with
whatever is different they want to see. No tie in with the original
soap. Sometimes that soap takes over and other times it just sits
there and goes away after 8 months.
We could look at starting a new brand. But, I don't think your
Harley-Davidson analogy applies, because we're not using this to break
into a new market. We're using this to make sure that we remain
relevant as the market we are in changes. Let's take the current shift
to electric cars as a branding analogy — GM *could* have gone with a
whole new name, but instead we have the Chevrolet Volt. (And Nissan
Leaf. And Ford is even reusing the "Focus" name.)
I think this matches our current and upcoming challenge more closely.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:02 a.m.
On Mon, 17 Jul 2017 10:10:16 -0400
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
We could look at starting a new brand. But, I don't think your
Harley-Davidson analogy applies, because we're not using this to break
into a new market. We're using this to make sure that we remain
relevant as the market we are in changes.
Except the whole market isn't changing. It is just a new niche opening
up. It's like Gnome3 deciding to convert the desktop interface for
mobile, creating a hybrid that tries to satisfy both, but hits the
sweet spot for neither. They would have been better off with a new
product targeted at mobiles exclusively, called maybe goblin or pixie,
while retaining their old brand, gnome2, to satisfy existing desktop
users who were happy with the paradigm embodied in that brand.
Let's take the current shift
to electric cars as a branding analogy — GM *could* have gone with a
whole new name, but instead we have the Chevrolet Volt. (And Nissan
Leaf. And Ford is even reusing the "Focus" name.)
I think this matches our current and upcoming challenge more closely.
I think you are agreeing with him. GM didn't convert the chevy malibu
to electric. They created a new brand. People who want an IC malibu
still can buy one, and know it isn't going to be electric tomorrow,
leaving them high and dry. And those who want to dip a toe into the
Ecar market, can try it out from a brand they trust. Just like the
soap analogy.
In my opinion, the equivalent for fedora would be to create a new spin
called gatsby or homburg that uses flatpaks. Maybe one waxes and one
wanes. Or maybe there is a fork. But what is being discussed now is
making an all or nothing bet on a new technology. Once rpm is ripped
out of fedora, it won't be coming back, in practical terms. There's a
burning the ships sort of appeal in that approach, but it isn't the
most prudent path from an expected value perspective.
10:06 a.m.
On 07/15/2017 01:43 PM, Matthew Miller wrote:
On Fri, Jul 14, 2017 at 02:56:34PM -0700, Andrew Lutomirski wrote:
> This is only a problem because Flatpak is currently following the IMO
> rather busted old Android model. With very few, if any, exceptions, I
> think a much better model would be for an application to start with
> basically no permissions and to have to ask for fine-grained
> permissions as needed. Think iOS but tighter. By default, an app
> shouldn't be able to use the network, see what other applications are
> installed, or get your unique advertising ID without explicit consent,
> let alone access your dotfiles.
I don't agree. With this model, every time you try to do something,
you're bombarded with questions asking if you want to do the thing you
tried to do. It gets very easy to fall into a default of clicking a
bunch of yesses all the time. That serves no *real* security benefit
and yet adds to user annoyance. There's gotta be a better way than
that.
That depends whether the process Andrew described happens every time you
run the app, or only when the packager prepares a flatpack, in which
case the annoying questions are asked of the knowledgeable packager, and
only once. Of course this assumes that it's practical to do a complete
run-through of all the different code paths, which may be questionable
for large apps.
10:30 a.m.
On Mon, 17 Jul 2017 12:45:27 +0200
Michael Stahl <mstahl(a)redhat.com> wrote:
On 16.07.2017 14:10, Kevin Kofler wrote:
> Debarshi Ray wrote:
>> How about reliable online updates of running applications as a
>> benefit?
>
> Upgrading RPM applications online just works. I do it all the time.
> The KDE tools do not even implement offline updates (and IMHO
> that's a good thing). The worst that can happen is that some
> recalcitrant applications (by far the minority) need to be
> restarted after updating (or if you upgraded the whole desktop,
> then your session may need to be restarted after updating). Until
> you do that, the current session may be "hosed" to some extent, but
> restarting will fix it.
no, the worst case is this:
https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-whe...
Anecdotal confirmation of the assertion in that link that running dnf
(or formerly yum) from a virtual console is a good way to go. I've
only done updates that way in stable versions since Fedora 3 and have
never had an update issue because of the update process. In rawhide, I
always run dnf updates that way, but without X running because of the
less stable environment. Again, no update issues.
I guess it's about balancing the level of risk with the cost of
mitigating risk. How much is it worth in various dimensions to go
another sigma lower in risk? For me, the above cost in process yields a
risk I can live with.
10:31 a.m.
On Mon, Jul 17, 2017 at 08:02:10AM -0700, stan wrote:
making an all or nothing bet on a new technology. Once rpm is
ripped
out of fedora, it won't be coming back, in practical terms. There's a
burning the ships sort of appeal in that approach, but it isn't the
most prudent path from an expected value perspective.
No one is talking about "ripping RPM out of Fedora".
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:31 a.m.
stan píše v Po 17. 07. 2017 v 08:02 -0700:
On Mon, 17 Jul 2017 10:10:16 -0400
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
> We could look at starting a new brand. But, I don't think your
> Harley-Davidson analogy applies, because we're not using this to
> break
> into a new market. We're using this to make sure that we remain
> relevant as the market we are in changes.
Except the whole market isn't changing. It is just a new niche
opening
up. It's like Gnome3 deciding to convert the desktop interface for
mobile, creating a hybrid that tries to satisfy both, but hits the
sweet spot for neither. They would have been better off with a new
product targeted at mobiles exclusively, called maybe goblin or
pixie,
while retaining their old brand, gnome2, to satisfy existing desktop
users who were happy with the paradigm embodied in that brand.
> Let's take the current shift
> to electric cars as a branding analogy — GM *could* have gone with
> a
> whole new name, but instead we have the Chevrolet Volt. (And Nissan
> Leaf. And Ford is even reusing the "Focus" name.)
>
> I think this matches our current and upcoming challenge more
> closely.
I think you are agreeing with him. GM didn't convert the chevy
malibu
to electric. They created a new brand. People who want an IC malibu
still can buy one, and know it isn't going to be electric tomorrow,
leaving them high and dry. And those who want to dip a toe into the
Ecar market, can try it out from a brand they trust. Just like the
soap analogy.
Except they didn't really create a new car brand, just a model brand.
No one is saying Fedora for desktop will be all flatpaks from now on.
There will be another flavour that will be called Fedora Atomic
Workstation alongside RPM-based Fedora Workstation. Just like
Chevrolet has electric Volt and traditional Malibu at the same time.
But no one in GM/Chevrolet is saying: No, the Chevrolet brand is
associated with combustion engines and it will stay that way forever.
GM is not spinning a new car company/brand for electric cars.
You say that they keep Malibu for people who want traditional cars, but
for how long? No one in GM is not gonna give you any promises because
if the market eventually shifts to electric cars they will just stop
doing the traditional cars. But the Chevrolet brand will stay.
I agree with Matt here, Fedora Project's mission (neither the old one,
nor the new draft) doesn't say anything about RPM. RPM is just means to
an end, not the goal. And I don't know why Fedora should be tied to RPM
forever. Really successful brands don't die when their current solution
stops being relevant, really successful brands are able to transition
themselves and stay relevant as the market shifts.
BTW we already have an official edition which doesn't use RPM as a
delivery system - Fedora Atomic and it's been part of the Fedora
Project for several years.
Jiri
In my opinion, the equivalent for fedora would be to create a new
spin
called gatsby or homburg that uses flatpaks. Maybe one waxes and one
wanes. Or maybe there is a fork. But what is being discussed now is
making an all or nothing bet on a new technology. Once rpm is ripped
out of fedora, it won't be coming back, in practical terms. There's
a
burning the ships sort of appeal in that approach, but it isn't the
most prudent path from an expected value perspective.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
10:45 a.m.
On 17 July 2017 at 10:10, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Sun, Jul 16, 2017 at 01:17:25PM -0400, Stephen John Smoogen
wrote:
> These sorts of deep brand issues are why most companies start new
> brands which might look like they are competing with their primary
> one. It can showcase some new identity and get people to see it as
> useful or better than what they have already. It can also show where
> things aren't going to work at all because people just aren't
> interested in something. The Soap industry is a classic study in
> brands where most people buy things because of something they tie to
> the brand be it a logo, a smell, a look or even just the container it
> comes in. Whenever the company changes those things, it causes
> significant drop in sales and they are usually going back to what they
> had. So instead a soap company will just start a new line with
> whatever is different they want to see. No tie in with the original
> soap. Sometimes that soap takes over and other times it just sits
> there and goes away after 8 months.
We could look at starting a new brand. But, I don't think your
Harley-Davidson analogy applies, because we're not using this to break
into a new market. We're using this to make sure that we remain
If you change something associated with your brand, you are making a
new market. It doesn't matter if we were going from RPM to
Flatpack+RPM or going from Blue to Purple. The people who associate
with the older brand are going to be shocked/bewildered/confused and
the new people are going to need to be convinced that RPM+Flatpack is
better than .deb+Snap.
Yes this isn't rational but humans are anything but rational. It is a
gut feeling and you need to use psychology to deal with it.
relevant as the market we are in changes. Let's take the current
shift
to electric cars as a branding analogy — GM *could* have gone with a
whole new name, but instead we have the Chevrolet Volt. (And Nissan
Leaf. And Ford is even reusing the "Focus" name.)
Those are sub-brands where you can experiment on things.
GM -> Chevrolet -> Camaro
GM -> Chevrolet -> Corvette
GM -> Chevrolet -> Tahoe
GM -> Chevrolet -> Volt.
That is a branded name chain and it has a brand strategy of "You trust
Chevrolet and you trust GM. So you can trust the Volt because it came
from that chain". [Or the opposite if you don't like GM or
Chevrolet..] And if I go into a Chevrolet dealership I am going to
expect certain things because I know other Chevrolet cars. [4 wheels,
doors in regular spots, engine in the front, power, dealership help]
Fedora -> Workstation
Fedora -> Server
Fedora -> Atomic
sort of works in this context. However we are not taking the "we are
making the Volt" as a sub-brand. Instead we are saying "So all our
vehicles are going to be hybrids in 18 months." which is more of the
Volvo approach but they are going with a 4 year approach to get their
brand story in place about why and how they are doing it.
Look at all the pain and suffering that the dnf people have had to go
through for the last 3 years because dnf is not yum but it kept having
to be so because people expected it to be. Now multiply this by 10
because we are talking about something lower down in the guts where
everything from every spec file writing doc needs an update and every
'rpm -V' only covers some part of the OS.
Look I am not against moving this to a new format. I guess I am just
tired of the merry-go-round of "completely new feature that people say
will cause problems", "those are just complainers", "oh look we have
to rethink all these things and make it like what we had because those
complainers did have some legitimate concerns", "we had to miss our
market window because we were too aggressive", "well maybe if we come
up with this completely new feature..."
And with that I am going to bow out here as what I was hoping was
going to be "could we plan this out a bit longer" is coming across as
"stop". This wasn't helpful to the dnf people and burnt a good many
developers out completely from floss and I am not going to be part of
the burn out the flatpack group.
I think this matches our current and upcoming challenge more closely.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
10:51 a.m.
There's a
burning the ships sort of appeal in that approach,
Actually, the correct analogy would be "burning platform" (and we all know how
well that ended).
Flatpacks are an unproven tech that can still crash and burn in the market.
Even if it eventually succeeds crash-landing it in Fedora while half the security and
management tools are lacking is a great way for the distribution to get an awful
reputation, while others will rip the fruits of this work some years later.
It would be nice, for once, if the desktop team could integrate its latest idea in the
distribution, and remove deprecated parts once the replacements are mature, instead of
forcing on everyone half-assed software, with half the bits missing, no alternatives, and
years of bad blood while they insist it is good enough and users are wrong to expect
working workflows (yay for echo chamber effects and devs agreeing with themselves they are
right but persecuted).
ie:
1. make flatpacked sofware behave like rpms in all the rpm-centric management tools, and
remove the rpm layer only when everyone *in* *the* *Fedora* *universe* agrees it is not
needed anymore and the replacements are better.
2. make a wayland, not a gnome 3.0
Regards,
--
Nicolas Mailhot
11:30 a.m.
On Mon, 17 Jul 2017 11:31:54 -0400
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
No one is talking about "ripping RPM out of Fedora".
I'm glad to hear it. I have a tendency to hyperbole in this noisy
world.
On 07/10/2017 09:31 PM, Owen Taylor wrote:
F29: packagers (of graphical applications) must create Flatpaks of
their applications if possible. They *may* keep standard RPM
packaging.
I interpreted this as such a death knell. I think if it's not required,
it's on its way out. It is a short step from there to
F31: packagers of graphical applications must create Flatpacks of their
applications, and standard RPM packaging will not be allowed for
such applications.
That said, flatpaks might turn out to be the greatest thing since
sliced bread, and they certainly have their use cases, as described by
contributors to this thread. In ten years, maybe everyone will be
using flatpak equivalent technology, and I'll be just another luddite
has been.
11:58 a.m.
----- Original Message -----
> There's a
> burning the ships sort of appeal in that approach,
Actually, the correct analogy would be "burning platform" (and we all know
how well that ended).
Flatpacks are an unproven tech that can still crash and burn in the market.
Even if it eventually succeeds crash-landing it in Fedora while half the
security and management tools are lacking is a great way for the
distribution to get an awful reputation, while others will rip the fruits of
this work some years later.
It would be nice, for once, if the desktop team could integrate its latest
idea in the distribution, and remove deprecated parts once the replacements
are mature, instead of forcing on everyone half-assed software, with half
the bits missing, no alternatives, and years of bad blood while they insist
it is good enough and users are wrong to expect working workflows (yay for
echo chamber effects and devs agreeing with themselves they are right but
persecuted).
ie:
1. make flatpacked sofware behave like rpms in all the rpm-centric management
tools, and remove the rpm layer only when everyone *in* *the* *Fedora*
*universe* agrees it is not needed anymore and the replacements are better.
2. make a wayland, not a gnome 3.0
However we end up doing it, I think it'd be better if we could do it without
you, whatever it is you do for Fedora. We, and certainly I, don't want this
level of toxicity and utter malfeasance on a mailing-list that I'm supposed
to be subscribed to.
Please, do leave, so you don't have to endure our apparent incompetence.
12:22 p.m.
On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
Matthew Miller wrote:
> I strongly dispute the idea that Fedora must be tied to a particular
> packaging technology.
The particular packaging technology is what ensures that we have a coherent,
integrated system. Flatpaks by design cannot offer the kind of integration
that native packages can offer, neither in terms of using shared system
libraries (saving space), nor in terms of user experience (even with
"portals", there will always be kinds of interoperation that the sandbox
just cannot allow).
And if the users will get their packages in a generic format rather than a
native Fedora format, what advantage do they get from getting it from Fedora
to begin with? The point of delivering Fedora packages is to integrate them
into the distribution. Only native packages can provide that.
Exactly, upstreams might as well just deliver .zip files which unpack
into a single directory and provide a ./application.sh script to set
up the LD_LIBRARY_PATH and cgroups right. That's basically what we're
talking about here when you strip it back to the essentials.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
12:26 p.m.
On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
On 16.07.2017 12:54, Richard W.M. Jones wrote:
> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>>
>>> If RPMs of the graphical application work fine now, what on earth is
>>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
>>> of them - as already explained, sandboxing is orthogonal to packaging.
>>
>> Huh? How would you get sandboxing without Flatpaks? Unless you are
>> proposing a different sandboxing technology.
>
> Things like libvirt-sandbox have been around for a really long time
> and don't require special packaging (in fact they work with any
> arbitrary command).
reading between the lines of the fine documentation, there is no mention
of X11 or GUI applications, so i guess "arbitrary" is a bit of an
exaggeration?
It seems like it's not mentioned in the docs, but it does work as in
this example of running evince to view a suspect PDF file:
https://honk.sigxcpu.org/con/More_sandboxing.html
BTW libvirt sandbox allows either full-virt or container sandboxing.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
12:27 p.m.
----- Original Message -----
On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
> > I strongly dispute the idea that Fedora must be tied to a particular
> > packaging technology.
>
> The particular packaging technology is what ensures that we have a
> coherent,
> integrated system. Flatpaks by design cannot offer the kind of integration
> that native packages can offer, neither in terms of using shared system
> libraries (saving space), nor in terms of user experience (even with
> "portals", there will always be kinds of interoperation that the sandbox
> just cannot allow).
>
> And if the users will get their packages in a generic format rather than a
> native Fedora format, what advantage do they get from getting it from
> Fedora
> to begin with? The point of delivering Fedora packages is to integrate them
> into the distribution. Only native packages can provide that.
Exactly, upstreams might as well just deliver .zip files which unpack
into a single directory and provide a ./application.sh script to set
up the LD_LIBRARY_PATH and cgroups right. That's basically what we're
talking about here when you strip it back to the essentials.
That's about as accurate as me saying that virtualisation is essentially
using the CPU's builtin virtualisation functionality when you strip it back
to the essentials.
12:54 p.m.
On Mon, Jul 17, 2017 at 09:48:46AM +0100, Daniel P. Berrange wrote:
On Sat, Jul 15, 2017 at 05:17:44PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > 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.
> >
> > If I look at this from my POV as the upstream maintainer of a graphical
> > application wishing to make it widely available to users of many distros.
> > The question is whether it is beneficial for me to join Fedora packaging
> > world to package my app, or whether to package it standalone as a flatpak
> > and never get involved in Fedora at all.
> >
> > With the proposed F27 rule here, I would have less work todo if I just
> > built my app as a flatpak, as I can avoid creating RPMs and just build
> > a single flatpak that should work on all distros. IOW by mandating
> > continued creation of RPMs, alongside flatpaks, we would be discouraging
> > people from becoming Fedora maintainers.
> >
> > Thus could suggest more flexibility - require continued maint of RPMs
> > for *existing* applications in Fedora only, to give some grace period
> > where we figure out how to provide a seemless upgrade path for people
> > who have an existing RPM installed to magically replace it with flatpak.
> > Anyone wishing to package a *new* application in F27, however, should be
> > able to straight to flatpaks only as there's no upgrade path issue to
> > worry about.
> >
> > This would encourage upstream app maintainers to join Fedora to make
> > use of the review, build & distribution mechanisms for flatpaks, without
> > forcing them todo extra work to create RPMs too.
>
> This depends on how exactly flatpacks are built:
> - if first an rpm is built, and then flatpack is built out of rpms,
> it's strictly more work (although there are benefits to users of installing
> using flatpacks over plain rpms, so it's an actual benefit for users
> and hence not pointless).
>
> - if one is building a _leaf_ application, and all deps are available as
> rpms, then the packager doesn't need to follow the strict rpm rules,
> and if they only build a flatpack without the intermediate rpm,
> some work is saved.
>
> - if one is building an application that anything else depends on, things
> get more complicated.
> (Let's take inkscape as an example: it's a end-user graphical
application,
> but it has command-line mode where it converts svgs to pngs and such,
> so it might be used e.g. when generating documentation or in %check
> for another package.)
>
> If inkscape is still available as rpm, it can be used as a dep in building
> other rpms. If however inkscape suddenly becomes available only as a flatpack,
> how does that work? Do we allow rpms to specify BuildRequires: inkscape.flatpack,
> and koji will install it and make the application available?
> Even if technically possible in the future, I don't think it's
> something we'd want to commit to right now.
Yeah, that last point is the real difficult issue, it forces you to keep
the RPM in parallel with the flatpak, unless we were to either change
RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
to pull in it contents.
I have to say that I find the opposite approach (find a way to auto-generate
a flatpak from RPM) much more appetizing. It's much more efficient
(flatpaks are often two orders of magnitude bigger, so pulling in any
number of flatpaks as build deps would have a noticeable deleterious effect
on build speed, because buildroot generation is the slowest step for many
packages), and much more aligned with existing infrastructure (iiuc, that's
how some flatpaks are built today, so it's almost there, except for the
"automatic" part), and makes more sense in general (build large things out
of small, instead of wrapping a big thing to make it pretend to be small.)
> So in the end, flatpacks as an *additional* distribution
mechanism
> sound fine. But if they become the *only* distribution mechanism, we
> risk that the whole ecosystem of packages which can all be used to
> build one another falls apart.
I guess one key question is how often the Inkscape situation arises where
a graphical application can be considered both a leaf node, and a dependancy
for other arbitrary app.
At lower levels of the stack, we know that the dependency graph is
effectively almost strongly connected (c.f. the efforts of the Base
Working Group and Harald Hoyer's graphs,
https://harald.fedorapeople.org/base-build-fc26-20170125/base-build.svg).
At the higher level, I don't think anybody has made much research, but
I expect that a) there's much more leaf nodes, b) there's still enough
deps on the graphical packages to require rpms.
For inkscape, eog, firefox:
$ dnf repoquery --disablerepo=\* --enablerepo=fedora-source --arch=src --whatrequires
inkscape
bacula-docs-0:7.4.7-1.fc26.src
djvulibre-0:3.5.27-2.fc26.src
gnome-colors-icon-theme-0:5.5.1-10.fc26.src
gnome-documents-0:3.24.2-1.fc26.src
pacemaker-0:1.1.17-0.1.rc4.fc26.src
tuxanci-0:0.21.0-4.fc26.src
vfrnav-0:20160429-7.fc26.src
$ ... --whatrequires eog
(nothing)
$ ... --whatrequires firefox
freewrl
Zbyszek
1:26 p.m.
On 07/14/2017 05:04 PM, Richard Hughes wrote:
On 14 July 2017 at 20:28, Andreas Tunek
<andreas.tunek(a)gmail.com> wrote:
> Is this really more reliable than using dnf (for graphical packages
> like Recepies and Builder)?
It's hugely more reliable. You can't actually trust rpm to do anything
atomically, and this is the main reason we force upgrade to be offline
in the workstation product. Just doing this one step reduced the
number of people experiencing the dead-system-after-upgrading bugs by
two order of magnitude, but it SUCKS to have to reboot to apply
application updates. Doing live updates with rpm is a bit like doing
maintenance on your car engine while driving down the freeway. Most of
the time it's fine, and you feel awesome. 0.001% of the time you die
in a huge fireball.
I'm sure some people are aware but for those who aren't it is worth noting
that we have an entire edition (atomic host) that is built around atomic
updates for rpm content. We are starting to make progress with a workstation
variant that is built on the same technology.
[1] https://getfedora.org/atomic/download/
[2]
https://download.fedoraproject.org/pub/fedora/linux/releases/26/Workstati...
1:48 p.m.
On 17.07.2017 19:26, Richard W.M. Jones wrote:
On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
> On 16.07.2017 12:54, Richard W.M. Jones wrote:
>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>>>
>>>> If RPMs of the graphical application work fine now, what on earth is
>>>> the point of forcing packagers to make Flatpaks? Sandboxing isn't
one
>>>> of them - as already explained, sandboxing is orthogonal to packaging.
>>>
>>> Huh? How would you get sandboxing without Flatpaks? Unless you are
>>> proposing a different sandboxing technology.
>>
>> Things like libvirt-sandbox have been around for a really long time
>> and don't require special packaging (in fact they work with any
>> arbitrary command).
>
> reading between the lines of the fine documentation, there is no mention
> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
> exaggeration?
It seems like it's not mentioned in the docs, but it does work as in
this example of running evince to view a suspect PDF file:
https://honk.sigxcpu.org/con/More_sandboxing.html
says:
Note that the above example shares /tmp with the sandbox in order to
give it access to the X11 socket. A better isolation can probably be
achieved using xpra or xvnc but I haven't looked into this yet.
so it doesn't actually sandbox very much, with access to the X11 socket
the app can keylog and inject shell commands into terminal windows as
much as it likes.
BTW libvirt sandbox allows either full-virt or container sandboxing.
i'd hope if you don't use containers but full-virt it's going to use
something more secure, like SPICE or something to display the GUI?
but i'd call virtualization a bit of a heavy-weight approach.
... there's more prior art, the SELinux "sandbox -X", which at least
starts a nested Xephyr for your convenience.
http://danwalsh.livejournal.com/31146.html
http://danwalsh.livejournal.com/31247.html
these have in common that they're generally not very user friendly: you
have to set up which files the program will have access to when you
start it; also copy/paste probably doesn't work between the nested X
server, which may or may not be a feature.
FlatPak portals have the potential to be more user friendly since you
can use the application's normal file picker to open files and the
application only gets access to the file the user chooses.
2:14 p.m.
On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl <mstahl(a)redhat.com> wrote:
On 17.07.2017 19:26, Richard W.M. Jones wrote:
> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
>> On 16.07.2017 12:54, Richard W.M. Jones wrote:
>>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
>>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>>>>
>>>>> If RPMs of the graphical application work fine now, what on earth is
>>>>> the point of forcing packagers to make Flatpaks? Sandboxing
isn't one
>>>>> of them - as already explained, sandboxing is orthogonal to
packaging.
>>>>
>>>> Huh? How would you get sandboxing without Flatpaks? Unless you are
>>>> proposing a different sandboxing technology.
>>>
>>> Things like libvirt-sandbox have been around for a really long time
>>> and don't require special packaging (in fact they work with any
>>> arbitrary command).
>>
>> reading between the lines of the fine documentation, there is no mention
>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
>> exaggeration?
>
> It seems like it's not mentioned in the docs, but it does work as in
> this example of running evince to view a suspect PDF file:
>
> https://honk.sigxcpu.org/con/More_sandboxing.html
says:
Note that the above example shares /tmp with the sandbox in order to
give it access to the X11 socket. A better isolation can probably be
achieved using xpra or xvnc but I haven't looked into this yet.
so it doesn't actually sandbox very much, with access to the X11 socket
the app can keylog and inject shell commands into terminal windows as
much as it likes.
> BTW libvirt sandbox allows either full-virt or container sandboxing.
i'd hope if you don't use containers but full-virt it's going to use
something more secure, like SPICE or something to display the GUI?
but i'd call virtualization a bit of a heavy-weight approach.
... there's more prior art, the SELinux "sandbox -X", which at least
starts a nested Xephyr for your convenience.
http://danwalsh.livejournal.com/31146.html
http://danwalsh.livejournal.com/31247.html
these have in common that they're generally not very user friendly: you
have to set up which files the program will have access to when you
start it; also copy/paste probably doesn't work between the nested X
server, which may or may not be a feature.
FlatPak portals have the potential to be more user friendly since you
can use the application's normal file picker to open files and the
application only gets access to the file the user chooses.
Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.
--
真実はいつも一つ！/ Always, there's only one truth!
3:06 p.m.
On 07/17/2017 03:14 PM, Neal Gompa wrote:
On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl
<mstahl(a)redhat.com> wrote:
> On 17.07.2017 19:26, Richard W.M. Jones wrote:
>> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
>>> On 16.07.2017 12:54, Richard W.M. Jones wrote:
>>>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
>>>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>>>>> If RPMs of the graphical application work fine now, what on earth
is
>>>>>> the point of forcing packagers to make Flatpaks? Sandboxing
isn't one
>>>>>> of them - as already explained, sandboxing is orthogonal to
packaging.
>>>>> Huh? How would you get sandboxing without Flatpaks? Unless you are
>>>>> proposing a different sandboxing technology.
>>>> Things like libvirt-sandbox have been around for a really long time
>>>> and don't require special packaging (in fact they work with any
>>>> arbitrary command).
>>> reading between the lines of the fine documentation, there is no mention
>>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
>>> exaggeration?
>> It seems like it's not mentioned in the docs, but it does work as in
>> this example of running evince to view a suspect PDF file:
>>
>> https://honk.sigxcpu.org/con/More_sandboxing.html
> says:
>
> Note that the above example shares /tmp with the sandbox in order to
> give it access to the X11 socket. A better isolation can probably be
> achieved using xpra or xvnc but I haven't looked into this yet.
>
> so it doesn't actually sandbox very much, with access to the X11 socket
> the app can keylog and inject shell commands into terminal windows as
> much as it likes.
>
>> BTW libvirt sandbox allows either full-virt or container sandboxing.
> i'd hope if you don't use containers but full-virt it's going to use
> something more secure, like SPICE or something to display the GUI?
>
> but i'd call virtualization a bit of a heavy-weight approach.
>
> ... there's more prior art, the SELinux "sandbox -X", which at least
> starts a nested Xephyr for your convenience.
>
> http://danwalsh.livejournal.com/31146.html
> http://danwalsh.livejournal.com/31247.html
>
> these have in common that they're generally not very user friendly: you
> have to set up which files the program will have access to when you
> start it; also copy/paste probably doesn't work between the nested X
> server, which may or may not be a feature.
>
> FlatPak portals have the potential to be more user friendly since you
> can use the application's normal file picker to open files and the
> application only gets access to the file the user chooses.
Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.
I read this like containers are something new and interesting. Upstream
docker project started this effort a few years ago and the world has
latched onto it. Fedora needs to adjust and become great at
containers. Some of the interesting work we have been doing with atomic
host, and atomic workstation is great. We don't have to continue to do
things the way we have for 20 years. I believe Fedora needs to be at
the forefront of figuring out these container issues. Flatpacks
integration into the desktop gives us the potential of a great leap
forwards in security. Imagine if Fedora finally fixes the biggest
security issue of the desktop by running browsers in containers, in a
truly secure manner with it fully integrated, not hacked up like it is
in the SELinux Sandbox or by running docker images like Jess Frazelle was.
The stuff that flatpack is doing has been very good.
Colin Walters work on ostree and rpm-ostree is looking into how we can
do offline updates already and yet this discussion is ignoring it. This
stuff is great and it is currently controlled by Fedora we should be
taking advantage of it. I run the atomic workstation now and am running
flatpack, as well as development environments in containers. I feel
some pain, but we are learning how to deal with it.
We need to learn to live with combinations of rpm packages, ostree
distributions and containers running on Fedora.
3:29 p.m.
On Sat, 2017-07-15 at 13:43 -0400, Matthew Miller wrote:
On Fri, Jul 14, 2017 at 02:56:34PM -0700, Andrew Lutomirski wrote:
> This is only a problem because Flatpak is currently following the
> IMO
> rather busted old Android model. With very few, if any, exceptions,
> I
> think a much better model would be for an application to start with
> basically no permissions and to have to ask for fine-grained
> permissions as needed. Think iOS but tighter. By default, an app
> shouldn't be able to use the network, see what other applications
> are
> installed, or get your unique advertising ID without explicit
> consent,
> let alone access your dotfiles.
I don't agree. With this model, every time you try to do something,
you're bombarded with questions asking if you want to do the thing
you tried to do. It gets very easy to fall into a default of clicking
a bunch of yesses all the time. That serves no *real* security
benefit and yet adds to user annoyance. There's gotta be a better way
than that.
Flatpak doesn't really use either the old or new Android model - it
*does* try to have a better way of doing things.
There are a static set of upfront permissions that are associated with
the application - this is likely what Andy is thinking of. While they
are reasonably fine-grained, they are low-level we are unlikely to
present them in the user's default view as more than "sandboxed" vs.
"unsandboxed" - some permissions can be considered to be pretty safe
(talk to Wayland, talk to the external network), and others entirely
not safe (talk to X11, read/write the user's home directory.)
These are not going to be used for things like "can read and write my
contacts", "can access my computer's camera", and whatever else
Android
bugs you about - those use cases are handled by portals.
The primary user interaction of a portal is to show a user interface
for the task (opening a file, sending an email, printing, etc.) - and
let the user decide if they want to proceed or not. In the minority of
case where this doesn't make much sense - say access to GPS - then the
portal asks the user similar to the new Android style and implements
smart memory behavior.
Regards,
Owen
4:40 p.m.
On Mon, 2017-07-17 at 17:51 +0200, nicolas.mailhot(a)laposte.net wrote:
> There's a
> burning the ships sort of appeal in that approach,
Actually, the correct analogy would be "burning platform" (and we all
know how well that ended).
I almost certainly should avoid responding to such an intentionally
inflammatory mail, but...
[...]
Even if it eventually succeeds crash-landing it in Fedora while half
the security and management tools are lacking is a great way for the
distribution to get an awful reputation, while others will rip the
fruits of this work some years later.
I'm entirely puzzled about how you think we could possibly land Flatpak
support in Fedora well integrated with our infrastructure, and our
security and management tools without starting to work on it, which is
essentially what this change proposal is about
Owen
5:02 p.m.
On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
The problem is that the RPMs that go into the Flatpaks are not FHS-
compliant, so the RPMs will have to carry some conditionals and be
built
twice.
Yes, that is true. Some apps will have to be patched for Flatpak, and
building them as both RPMs and Flatpaks is going to require
conditionals. So there will be some overhead if we support both.
I think that's probably worthwhile. The way I see it, we have a large
number of users who prefer an entirely RPM-based system, although most
users would be better off with an Atomic system and just layering a few
RPMs on top. I suspect we can satisfy both groups of users while doing
only a minimal amount of work. Making patches conditional is not so
hard.
Michael
5:03 p.m.
On Fri, 2017-07-14 at 21:29 +0200, Lars Seipel wrote:
On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanzaro(a)gnome.org
wrote:
> But we have not been. Very few applications actually have SELinux
> profiles,
> and they are all maintained downstream rather than upstream. The
> volume of
> erroneous SELinux denials in Bugzilla is too high, and the response
> time for
> fixing them too slow. SELinux profiles work best when they are
> maintained
> upstream by application developers who are familiar with SELinux,
> not by
> SELinux developers who are unfamiliar with the application.
We do have the same issue with sandbox policies for Flatpak,
no? This is the hard part of any sandboxing system and (judging from
the current docs) Flatpak hasn't tackled it yet.
A Flatpak app currently requires the following incantation to access
the host's dconf, so that it can behave like its users would expect:
> --filesystem=xdg-run/dconf
> --filesystem=~/.config/dconf:ro
> --talk-name=ca.desrt.dconf
> --env=DCONF_USER_CONFIG_DIR=.config/dconf
I think you've found a note in the docs pointing out one spot where
things aren't completely solved yet, and taken that as an example of a
huge class of problem, while that huge class of problems actually does
not exist.
Now, while this specific dconf issue might get solved at some point,
dconf won't be enough for the vast majority of useful apps. All the
crap that lives in the various dot files in your home directory and
elsewhere on the system and that affects the behaviour of a program
needs to be made available to the app. Other things must not be, such
as everything containing secrets.
You are over-estimating the amount of separate files that need to be
visible to an application. Other than their own files, most
applications just read standard files out of /etc, and those can be
propagated or stubbed out as necessary.
One big advantage of the namespace approach over the SELinux or seccomp
approach to create a sandbox is that if an application looks for some
file that is not exposed to the sandbox, it's just not there - it's not
a permission error or a crash.
But, yes, complex applications will not just sandbox as is - and to fix
that poking holes is not sufficient - you need to find safe ways of
doing the same things. The Flatpak model is to expect code changes in
applications, and expect that those code changes will happen upstream.
Owen
5:19 p.m.
On Mon, Jul 17, 2017 at 05:02:42PM -0500, Michael Catanzaro wrote:
I think that's probably worthwhile. The way I see it, we have a
large number of users who prefer an entirely RPM-based system,
although most users would be better off with an Atomic system and
just layering a few RPMs on top. I suspect we can satisfy both
groups of users while doing only a minimal amount of work. Making
patches conditional is not so hard.
I definitely would like to see as much "magic" and infrastructure
support as we can muster for this, so we avoid the complication of SCL
macros -- the original idea there was that the same spec files could be
used for non-SCL packages, and it got so complex that that didn't
really pan out.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:38 p.m.
Daniel Walsh wrote:
I read this like containers are something new and interesting.
Nope, we are saying they are something new and uninteresting. ;-)
Upstream docker project started this effort a few years ago and the
world
has latched onto it. Fedora needs to adjust and become great at
containers.
Why? Just because "the world has latched onto it", for some definition of
"the world", even if it does not bring us any benefit (because we already
have distribution technologies that are far superior)?
Some of the interesting work we have been doing with atomic host,
and
atomic workstation is great.
You and I clearly do not have the same definition of "great".
We don't have to continue to do things the way we have for 20
years.
But we also don't have to stop doing things the way we have been doing with
no issues for 20 years. Especially when the overhyped replacement is
actually worse and does away with the most important feature of our existing
software delivery mechanism (shared dependencies with automatic dependency
resolution).
I believe Fedora needs to be at the forefront of figuring out these
container issues.
Then it should be at the forefront of figuring out how to build virtual
containers from packaged content in /usr (as has been discussed elsewhere in
this thread) rather than shipping container blobs duplicating the world.
Flatpacks integration into the desktop gives us the potential of a
great
leap forwards in security. Imagine if Fedora finally fixes the biggest
security issue of the desktop by running browsers in containers, in a
truly secure manner with it fully integrated, not hacked up like it is
in the SELinux Sandbox or by running docker images like Jess Frazelle was.
My browser (QupZilla) is already sandboxed, without SELinux, without Docker,
and without Flatpak. (It uses the Chromium seccomp sandbox.)
The stuff that flatpack is doing has been very good.
You and I clearly do not have the same definition of "very good".
Colin Walters work on ostree and rpm-ostree is looking into how we
can
do offline updates already and yet this discussion is ignoring it. This
stuff is great and it is currently controlled by Fedora we should be
taking advantage of it. I run the atomic workstation now and am running
flatpack, as well as development environments in containers. I feel
some pain, but we are learning how to deal with it.
If you are a masochist, that is your problem. You don't have to force this
on all Fedora users.
The ostree technology removes the possibility to make any changes to the
base packages from the user, which makes it an extremely inflexible delivery
method. I do not want to use ostree, not now, not ever.
We need to learn to live with combinations of rpm packages, ostree
distributions and containers running on Fedora.
We don't need to at all. RPM will continue working, if it does not get
deliberately sabotaged by the proponents of containers.
Kevin Kofler
7:44 p.m.
Dusty Mabe wrote:
I'm sure some people are aware but for those who aren't it is
worth noting
that we have an entire edition (atomic host) that is built around atomic
updates for rpm content.
Atomic updates for "rpm content", but not for actual RPMs, unfortunately,
only for blobs composed on the server side from an unchangeable set of RPMs.
So it does not solve the problem at all.
Kevin Kofler
7:48 p.m.
Bastien Nocera wrote:
It's like you didn't listen to the arguments when this
feature was
implemented in Fedora years ago, and continue not to. You're wrong, and
the fact that you keep insisting you're not is frankly intellectual
dishonesty.
I am using online updates of RPMs all the time. How is it dishonest to say
that it just works for me, when this is the fact?
If you really believe you're correct, try to kill your X server
in the
middle of an upgrade...
That will actually not hurt at all if you upgrade through PackageKit (with a
frontend like plasma-pk-updates that does online updates) or dnfdaemon (with
Dnfdragora or Yumex-DNF), because those run outside of the X session, they
are activated off the D-Bus system bus (not the session bus).
Kevin Kofler
7:51 p.m.
Michael Stahl wrote:
no, the worst case is this:
https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-whe...
That was a one-time bug that is already fixed. It also affected only systems
with hybrid graphics, lots of systems were not affected at all. And as I
explained in my reply to Bastien Nocera, X crashing will still allow the
update to complete if you use PackageKit or dnfdaemon.
Kevin Kofler
7:58 p.m.
Daniel P. Berrange wrote:
Yeah, that last point is the real difficult issue, it forces you to
keep
the RPM in parallel with the flatpak, unless we were to either change
RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
to pull in it contents.
You need to keep the RPM anyway because there are users out there (e.g., me)
who are NOT going to install a Flatpak, but demand native packages.
Kevin Kofler
8:06 p.m.
Jiří Eischmann wrote:
I agree with Matt here, Fedora Project's mission (neither the old
one,
nor the new draft) doesn't say anything about RPM. RPM is just means to
an end, not the goal. And I don't know why Fedora should be tied to RPM
forever. Really successful brands don't die when their current solution
stops being relevant, really successful brands are able to transition
themselves and stay relevant as the market shifts.
You are implying there that RPM is (or will soon be) no longer relevant,
which is just not true. Flatpak does NOT deliver equivalent functionality.
Kevin Kofler
8:15 p.m.
Bastien Nocera wrote:
However we end up doing it, I think it'd be better if we could do
it
without you, whatever it is you do for Fedora. We, and certainly I, don't
want this level of toxicity and utter malfeasance on a mailing-list that
I'm supposed to be subscribed to.
Please, do leave, so you don't have to endure our apparent incompetence.
Nicolas Mailhot has done a lot of work on font packaging and organizing the
Fonts SIG. Asking an experienced contributor like him to leave is extremely
rude. All the more because you are just shooting the messenger. And you
yourself admitted that you did not even bother looking him up before ruling
him dispensable.
This kind of toxic attitude is absolutely unacceptable. How about YOU leave
instead?
Kevin Kofler
8:27 p.m.
On Tue, Jul 18, 2017 at 02:58:52AM +0200, Kevin Kofler wrote:
Daniel P. Berrange wrote:
> Yeah, that last point is the real difficult issue, it forces you to keep
> the RPM in parallel with the flatpak, unless we were to either change
> RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
> to pull in it contents.
You need to keep the RPM anyway because there are users out there (e.g., me)
who are NOT going to install a Flatpak, but demand native packages.
Kevin,
*please*, *please* tone down the negativity. You can "demand", but the
project is not bound by demands. You have to *convince* people. There
are good arguments to keep RPMs around, at least for the foreseeable future,
so don't burn them by non-technical posts.
Zbyszek
8:29 p.m.
Daniel P. Berrange wrote:
Use of RPM is merely a particular historical choice of delivery
mechanism,
and certainly not the defining characteristic of what it means to be the
Fedora distribution. For users consuming the Fedora desktop, the fact that
they're using RPM is hidden away as an implementation detail behind the
apps like GNOME software.
The choice of RPM as opposed to, say, dpkg/deb can be called "historical",
but the concept of delivering packages with dependencies and automatic
dependency resolution is very much a user-visible defining characteristic.
Many Fedora users do not use GNOME Software. Several spins ship Dnfdragora
as their package manager, which is based on DNF and RPM and actually shows
dependencies. There are also many users using the dnf command line directly.
And even the KDE equivalent of GNOME Software, Plasma Discover, now
reportedly shows what dependencies it is going to install when you install a
new package. (I don't know whether GNOME Software itself does that.)
And even if the UI tries to hide the difference, the inherent technical
differences between RPMs and Flatpaks WILL be noticed by the user. Download
sizes, behavior when a library is upgraded, etc.
Upstream still has to choose what base layer(s) they build their
application flatpak on top of, and thus Fedora is a clearly choice there.
Fedora also still provides the infrastructure for building flatpaks,
hosting to distribute and mirror them, review of flatpak image manifests,
quality testing before release, and more. Essentially the things that
Fedora already does for software provided via RPMs, are still beneficial
to at least some extent when using flatpaks.
I think Fedora deserves to be much more than just a runtime that a container
can choose to use within the container.
Kevin Kofler
9:18 p.m.
On 7/17/2017 10:22 AM, Richard W.M. Jones wrote:
On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
>> I strongly dispute the idea that Fedora must be tied to a particular
>> packaging technology.
> The particular packaging technology is what ensures that we have a coherent,
> integrated system. Flatpaks by design cannot offer the kind of integration
> that native packages can offer, neither in terms of using shared system
> libraries (saving space), nor in terms of user experience (even with
> "portals", there will always be kinds of interoperation that the sandbox
> just cannot allow).
>
> And if the users will get their packages in a generic format rather than a
> native Fedora format, what advantage do they get from getting it from Fedora
> to begin with? The point of delivering Fedora packages is to integrate them
> into the distribution. Only native packages can provide that.
Exactly, upstreams might as well just deliver .zip files which unpack
into a single directory and provide a ./application.sh script to set
up the LD_LIBRARY_PATH and cgroups right. That's basically what we're
talking about here when you strip it back to the essentials.
Rich.
The rediscovery of static binaries is basically what the entire industry
discussion comes down to, which last I checked were still anethema
within Fedora.
If people want a container and tarball-based OS, that's fine. There are
Linux-kernel-based projects that excel at that. Why drag Fedora into
that when it would be easier to create a new distribution focused
specifically on that? Flatpaks fall into the same category.
Fedora is only in the position it's in because it inherited the goodwill
of the original RedHat Linux distribution, and it (well, more
specifically, Rawhide) remains the de facto upstream standard for the
entire RPM-based community. If Fedora moves wholesale away from RPM, it
might result in an amazing OS for someone... but there's hardly any
reason for me to use it at all.
How many other fundamental changes need to be made to the core of the OS
because GNOME/FreeDesktop.org users have edge cases they need covered?
(If you think the previous changes have been well received, I'd invite
you to take a look at the CentOS users list.)
-jc
1:35 a.m.
> Even if it eventually succeeds crash-landing it in Fedora while
half
> the security and management tools are lacking is a great way for the
> distribution to get an awful reputation, while others will rip the
> fruits of this work some years later.
I'm entirely puzzled about how you think we could possibly land
Flatpak
support in Fedora well integrated with our infrastructure, and our
security and management tools without starting to work on it, which is
essentially what this change proposal is about
Working on it is fine. Improving it is fine. Proposing Fedora-generated Flatpacks outside
of Fedora is fine.
Planning to ship stuff as Flatpack only when basic questions such as inter-component
dependencies, automated deployment (kickstarts), actual network and disk use
(chromebooks), actual user adoption, actual convenience of the security model, etc are not
resolved is not. That's the hard and tedious stuff most people on this list care about
and GUI app writers, not a lot. That's the point of no easy return where Flatpack is
forced on users be it ready or not.
There is not a vast amount of trust given past history and the way some Flatpack
proponents clearly intend to shaft the methods that built Fedora (and its userbase) to
jumpstart something else.
--
Nicolas Mailhot
2:54 a.m.
----- Mail original -----
De: "Kevin Kofler"
> Please, do leave, so you don't have to endure our apparent
incompetence.
Nicolas Mailhot has done a lot of work on font packaging and
organizing the
Fonts SIG.
Thanks a lot Kevin. However, that really should not matter. Many people here make
Fedora/Centos/RHEL deployments happen, ultimately paying some people's salaries. This
is a lot of work (if not public). There is little reason to follow this list if you do not
contribute to the Fedora universe one way or the other.
Anyway let's close this branch of the thread, it is making me sick.
Regards,
--
Nicolas Mailhot
4:45 a.m.
Kevin Kofler píše v Út 18. 07. 2017 v 03:06 +0200:
Jiří Eischmann wrote:
> I agree with Matt here, Fedora Project's mission (neither the old
> one,
> nor the new draft) doesn't say anything about RPM. RPM is just
> means to
> an end, not the goal. And I don't know why Fedora should be tied to
> RPM
> forever. Really successful brands don't die when their current
> solution
> stops being relevant, really successful brands are able to
> transition
> themselves and stay relevant as the market shifts.
You are implying there that RPM is (or will soon be) no longer
relevant,
which is just not true. Flatpak does NOT deliver equivalent
functionality.
No, I'm not implying that RPM is no longer relevant, I'm implying that
it might not be relevant in the (even distant) future. I don't think no
one here wants to get rid of RPM while it's relevant. Just like car
companies are not ditching traditional cars because they're still very
much relevant, but if we keep RPM as a dogma with the mindset "I can't
ever imagine Fedora without RPM", we will drive ourselves into
irrelevancy if the market really shifts to something else eventually.
Maybe in 10 years we will find that RPM is still the best way to put
the OS together and ship it to users, maybe there will be better
alternatives, who knows and if Fedora doesn't explore these
alternatives early enough, yeah, then we will no longer be relevant as
an OS.
IMHO the mission of the Fedora Project is to provide a free OS, not a
necessarily an RPM distro. Yes, RPM has happened to be the way we put
the OS together since the beginning, but that doesn't mean we can't
look past that just like car companies which want to survive in the
long run are looking into electric and hydrogen cars although for their
whole history they have only produced cars with internal combustion
engines.
Jiri
6:23 a.m.
On Tuesday, 18 July 2017 at 00:02, Michael Catanzaro wrote:
On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler
<kevin.kofler(a)chello.at>
wrote:
> The problem is that the RPMs that go into the Flatpaks are not FHS-
> compliant, so the RPMs will have to carry some conditionals and be built
> twice.
Yes, that is true. Some apps will have to be patched for Flatpak, and
building them as both RPMs and Flatpaks is going to require conditionals. So
there will be some overhead if we support both.
I think this is unacceptable and a blocker. It didn't work with SCLs and
it won't work with Flatpak, either. Flatpaks must be possible to build
from unmodified RPMs or as part of RPM build process.
I think that's probably worthwhile. The way I see it, we have a
large number
of users who prefer an entirely RPM-based system, although most users would
be better off with an Atomic system and just layering a few RPMs on top.
Could you explain the benefits of Atomic system + few layered RPMs vs. a
traditional Fedora installation?
I suspect we can satisfy both groups of users while doing only a
minimal
amount of work. Making patches conditional is not so hard.
By the way, I can't figure out how to look inside a Flatpak and review its
contents. Could someone provide some pointers? With plain RPMs or yum repos
I can just download the binary RPM and extract it (rpm2cpio foo.rpm|cpio
-div). I can also examine metadata using rpm -qp -i -R --provides and so on.
What is the equivalent for Flatpak?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6:39 a.m.
On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski
wrote:
By the way, I can't figure out how to look inside a Flatpak and
review its contents. Could someone provide some pointers?
On the repo all you have is an object store (much like Git's
.git/objects/ folder), but if you install the app you will also get a
checkout:
$ ls ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/
bin lib manifest.json share
(that's because I installed the app with --user, if you install it
system-wide then it's under /var/lib/flatpak/app/...)
The manifest.json file is a recipe for how the app was built (like a
spec file), which helps reproducing builds.
The contents of that files/ directory are what gets mounted as /app/ in
the sandbox.
--
Mathieu
7:40 a.m.
Dne 18.7.2017 v 13:23 Dominik 'Rathann' Mierzejewski napsal(a):
On Tuesday, 18 July 2017 at 00:02, Michael Catanzaro wrote:
> On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler <kevin.kofler(a)chello.at>
> wrote:
>> The problem is that the RPMs that go into the Flatpaks are not FHS-
>> compliant, so the RPMs will have to carry some conditionals and be built
>> twice.
> Yes, that is true. Some apps will have to be patched for Flatpak, and
> building them as both RPMs and Flatpaks is going to require conditionals. So
> there will be some overhead if we support both.
I think this is unacceptable and a blocker. It didn't work with SCLs and
it won't work with Flatpak, either. Flatpaks must be possible to build
from unmodified RPMs or as part of RPM build process.
It didn't work for SCLs? How comes?
Vít
8:12 a.m.
On Tuesday, 18 July 2017 at 14:40, Vít Ondruch wrote:
Dne 18.7.2017 v 13:23 Dominik 'Rathann' Mierzejewski napsal(a):
> On Tuesday, 18 July 2017 at 00:02, Michael Catanzaro wrote:
>> On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler <kevin.kofler(a)chello.at>
>> wrote:
>>> The problem is that the RPMs that go into the Flatpaks are not FHS-
>>> compliant, so the RPMs will have to carry some conditionals and be built
>>> twice.
>> Yes, that is true. Some apps will have to be patched for Flatpak, and
>> building them as both RPMs and Flatpaks is going to require conditionals. So
>> there will be some overhead if we support both.
> I think this is unacceptable and a blocker. It didn't work with SCLs and
> it won't work with Flatpak, either. Flatpaks must be possible to build
> from unmodified RPMs or as part of RPM build process.
It didn't work for SCLs? How comes?
We don't have SCLs in Fedora. Having the one spec file for both Fedora
and SCL is a huge pain (I'm told).
Back on topic, I read a bit more and it seems like koji is going to
support building Flatpaks leveraging the already available container and
module backend, so this is starting to look good to me.
Regards,
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
8:25 a.m.
On Tuesday, 18 July 2017 at 13:39, Mathieu Bridon wrote:
On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann'
Mierzejewski
wrote:
> By the way, I can't figure out how to look inside a Flatpak and
> review its contents. Could someone provide some pointers?
On the repo all you have is an object store (much like Git's
.git/objects/ folder), but if you install the app you will also get a
checkout:
$ ls ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/
bin lib manifest.json share
(that's because I installed the app with --user, if you install it
system-wide then it's under /var/lib/flatpak/app/...)
The manifest.json file is a recipe for how the app was built (like a
spec file), which helps reproducing builds.
The contents of that files/ directory are what gets mounted as /app/ in
the sandbox.
In other words, it's not possible to inspect a binary flatpak without
installing it. With RPMs, I can check what files will land on my system
and where, and also see what the scriptlets do. I can also extract
and inspect individual files. Am I missing something and worrying
unnecessarily that I can't do the same with flatpaks?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
8:39 a.m.
On Tue, Jul 18, 2017 at 5:23 AM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
Could you explain the benefits of Atomic system + few layered RPMs
vs. a
traditional Fedora installation?
The OS itself is versioned and binary identical to any other
installation with the same version. There is no longer the
pathological behavior of everyone in effect having different sub
versions of Fedora because their package versions differ, because they
caught today's update, or yesterday's, or the before noon update, or
the one with the moon transitioning from crescent to gibbous.
By the way, I can't figure out how to look inside a Flatpak and
review its
contents. Could someone provide some pointers?
Good question.
Also, how to copy / push such apps to workstations. We're going on 18
years since .app bundles on macOS can be drag and drop copied to
install, and it's like, really no one has copied this? The easiest way
to put a second copy on another machine is to just download it again?
That's silly.
--
Chris Murphy
8:52 a.m.
On 18/07/17 14:39, Chris Murphy wrote:
On Tue, Jul 18, 2017 at 5:23 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
> Could you explain the benefits of Atomic system + few layered RPMs vs. a
> traditional Fedora installation?
The OS itself is versioned and binary identical to any other
installation with the same version. There is no longer the
pathological behavior of everyone in effect having different sub
versions of Fedora because their package versions differ, because they
caught today's update, or yesterday's, or the before noon update, or
the one with the moon transitioning from crescent to gibbous.
So what is the user experience of "updating" in this world? How does the
transition from one snapshot to the next occur?
> By the way, I can't figure out how to look inside a Flatpak
and review its
> contents. Could someone provide some pointers?
Good question.
Also, how to copy / push such apps to workstations. We're going on 18
years since .app bundles on macOS can be drag and drop copied to
install, and it's like, really no one has copied this? The easiest way
to put a second copy on another machine is to just download it again?
That's silly.
Well macOS stole "app as a directory" from RISC OS which pushes the idea
back about 30 years ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:52 a.m.
On Tue, Jul 18, 2017 at 03:29:00AM +0200, Kevin Kofler wrote:
> Fedora also still provides the infrastructure for building
flatpaks,
> hosting to distribute and mirror them, review of flatpak image manifests,
> quality testing before release, and more. Essentially the things that
> Fedora already does for software provided via RPMs, are still beneficial
> to at least some extent when using flatpaks.
I think Fedora deserves to be much more than just a runtime that a container
can choose to use within the container.
Absolutely. That's why I'm supportive of application-level delivery
experimentation like this.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:52 a.m.
On 18 July 2017 at 14:25, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
In other words, it's not possible to inspect a binary flatpak
without
installing it.
You can install it to /tmp... gnome-software actually "installs" the
flatpakref into a temp directory so that we can show the application
metadata without auto-installing the remote.
With RPMs, I can check what files will land on my system
and where, and also see what the scriptlets do.
I'd say this is a drawback; to see what the difference between
foo-1.0.rpm and foo-1.1.rpm you have to download both huge files, even
if the only thing that changed is one line in one header file. With
ostree you just fetch that one changed file and deploy it somewhere
else. Also, with flatpak there are no "scriptlets". Your OS is always
immutable and safe.
Am I missing something and worrying
unnecessarily that I can't do the same with flatpaks?
I think you're missing the question, i.e. rather than saying "You
can't do X with Flatpak!" you need to be saying "Can anyone please
tell me how do I do X with Flatpak?".
On a more general note I think a lot of people are assuming we're all
horrible evil people, trying to subvert the One True Fedora Way. This
is exceptionally poisonous and needs to stop, otherwise Fedora should
to drop both the "Friends", "Features" and the "First" in
its motto.
Richard.
8:55 a.m.
On Tue, Jul 18, 2017 at 08:35:58AM +0200, nicolas.mailhot(a)laposte.net wrote:
Working on it is fine. Improving it is fine. Proposing
Fedora-generated Flatpacks outside of Fedora is fine.
Planning to ship stuff as Flatpack only when basic questions such as
inter-component dependencies, automated deployment (kickstarts),
actual network and disk use (chromebooks), actual user adoption,
actual convenience of the security model, etc are not resolved is
not. That's the hard and tedious stuff most people on this list care
about and GUI app writers, not a lot. That's the point of no easy
return where Flatpack is forced on users be it ready or not.
*Planning* to do something when not all of the questions are answered
is a natural consequence of doing that planning in the open and as part
of a collaborative community rather than doing closed-source or
closed-source-like developement.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:55 a.m.
On 18 July 2017 at 14:52, Tom Hughes <tom(a)compton.nu> wrote:
So what is the user experience of "updating" in this world?
How does the
transition from one snapshot to the next occur?
Basically the same as now. Kalev added a gnome-software plugin that
downloads the new data, shows the OS update in gnome-software updates
panel and then you reboot, and it applies the update atomically. You
reboot, and you're in the new OS.
Richard.
8:56 a.m.
----- Original Message -----
Bastien Nocera wrote:
> However we end up doing it, I think it'd be better if we could do it
> without you, whatever it is you do for Fedora. We, and certainly I, don't
> want this level of toxicity and utter malfeasance on a mailing-list that
> I'm supposed to be subscribed to.
>
> Please, do leave, so you don't have to endure our apparent incompetence.
Nicolas Mailhot has done a lot of work on font packaging and organizing the
Fonts SIG.
"What it is you do for Fedora" was meant as "even if you package half of
the
distribution, it's irrelevant".
Asking an experienced contributor like him to leave is extremely
rude.
You probably skipped reading Nicolas' mail.
All the more because you are just shooting the messenger. And you
yourself admitted that you did not even bother looking him up before ruling
him dispensable.
That's what you don't understand. I don't want to work with 10x brogrammers
who
think they can get away with saying we are "forcing on everyone half-assed
software". I'll let you read the end of that sentence as well.
This kind of toxic attitude is absolutely unacceptable. How about YOU
leave
instead?
That's funny that you'd use the same vocabulary I used to describe Nicolas'
mail.
How is telling somebody who obviously thinks we're doing a bad job to leave
"toxic"?
9:01 a.m.
On Tue, Jul 18, 2017 at 02:52:57PM +0100, Richard Hughes wrote:
On a more general note I think a lot of people are assuming we're
all
horrible evil people, trying to subvert the One True Fedora Way. This
is exceptionally poisonous and needs to stop, otherwise Fedora should
to drop both the "Friends", "Features" and the "First" in
its motto.
Yes. Since we're not going to drop those, let's do the other thing, please.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:04 a.m.
On 18/07/17 14:52, Richard Hughes wrote:
On a more general note I think a lot of people are assuming we're
all
horrible evil people, trying to subvert the One True Fedora Way. This
is exceptionally poisonous and needs to stop, otherwise Fedora should
to drop both the "Friends", "Features" and the "First" in
its motto.
I'm not necessarily concerned about subverting (or "changing" as I would
prefer to think of it) the One True Fedora Way, if there are good
reasons to do so and it improves things.
I'm more concerned that there will no longer be One True Fedora Way.
By which I mean that there will no longer be one way to update a Fedora
system because workstations and servers have to be managed in completely
different ways.
In other words that it's no longer possible to use clusterssh to run
"dnf update" on twenty machines at once because each one is now a
special snowflake that requires it's own approach to updating things -
possibly even a mix of approaches if a developer's workstation needs
"server updates" to update postgres and apache and "workstation
updates"
to update gcc and firefox.
Hell, is gcc a "server" thing? or a "workstation" thing? or both if we
want to follow the true path of madness...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:06 a.m.
On 18/07/17 14:55, Richard Hughes wrote:
On 18 July 2017 at 14:52, Tom Hughes <tom(a)compton.nu> wrote:
> So what is the user experience of "updating" in this world? How does the
> transition from one snapshot to the next occur?
Basically the same as now. Kalev added a gnome-software plugin that
downloads the new data, shows the OS update in gnome-software updates
panel and then you reboot, and it applies the update atomically. You
reboot, and you're in the new OS.
Any answer that ends in "then you reboot" has instantly failed ;-)
I know you want us to reboot on every update but in the real world
nobody is doing that because it's insane.
If you really want us to do that then the thing to spend your time on is
ways to preserve desktop state across reboots. And yes I know that is
really, really hard which is why every attempt to do so has always been
abandoned. Nobody wants to have to resetup their desktop every day
though which is why we all just run dnf update and cope with the rare
occasions when an app crashes and we have to restart it.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:15 a.m.
On Tue, 2017-07-18 at 08:35 +0200, nicolas.mailhot(a)laposte.net wrote:
> > Even if it eventually succeeds crash-landing it in Fedora
while
> > half
> > the security and management tools are lacking is a great way for
> > the
> > distribution to get an awful reputation, while others will rip
> > the
> > fruits of this work some years later.
> I'm entirely puzzled about how you think we could possibly land
> Flatpak
> support in Fedora well integrated with our infrastructure, and our
> security and management tools without starting to work on it, which
> is
> essentially what this change proposal is about
Working on it is fine. Improving it is fine. Proposing Fedora-
generated Flatpacks outside of Fedora is fine.
If Fedora community members are using Fedora infrastructure to build
Flatpaks that's really by definition part of the Fedora project, isn't
it?
Planning to ship stuff as Flatpack only when basic questions such as
inter-component dependencies, automated deployment (kickstarts),
actual network and disk use (chromebooks), actual user adoption,
actual convenience of the security model, etc are not resolved is
not.
I think it's important to think ahead and be transparent about what we
are thinking about, so in that sense we're "planning" to ship things
Flatpak only. But I want to be clear that there is no *proposal* on the
table to ship things Flatpak only, and *no proposed timescale*. And
there won't be until we know how the tools work out for packagers, how
Flatpak usage works out for users, and we have a significant body of
Fedora packages built as Flatpaks to look at things like installed size
and network usage.
These are things we can only get to by building out the infrastructure
so that packagers can start trying building Flatpaks and users can
start trying installing them.
That's the hard and tedious stuff most people on this list care
about
and GUI app writers, not a lot. That's the point of no easy return
where Flatpack is forced on users be it ready or not.
There is not a vast amount of trust given past history and the way
some Flatpack proponents clearly intend to shaft the methods that
built Fedora (and its userbase) to jumpstart something else.
It's perfectly fine to be skeptical, it's perfectly fine to ask hard
questions about areas you think need more work.
But the only way that we get to something that is an evolution of how
Fedora currently works, that pays attention to the needs of current
Fedora users, and builds on the strengths of the Fedora infrastructure
and the people doing all the work in the Fedora community is to work on
it within Fedora.
Your earlier mail could definitely be taken to mean that we should go
off and work on Flatpak elsewhere, and when we have a fully working
ecosystem elsewhere, and have (on our own, without any engagement)
fully met all the needs of Fedora users, then we can look at
integrating that into Fedora. That sounds hard to distinguish from
ignoring Fedora and starting something else. :-)
Owen
9:19 a.m.
On Tuesday, 18 July 2017 at 15:39, Chris Murphy wrote:
On Tue, Jul 18, 2017 at 5:23 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
> Could you explain the benefits of Atomic system + few layered RPMs vs. a
> traditional Fedora installation?
The OS itself is versioned and binary identical to any other
installation with the same version. There is no longer the
pathological behavior of everyone in effect having different sub
versions of Fedora because their package versions differ, because they
caught today's update, or yesterday's, or the before noon update, or
the one with the moon transitioning from crescent to gibbous.
"One size fits everyone" approach can be dangerous. It never does, in
fact, fit everyone, and often sacrifices flexibility and resource usage
for the convenience of a single image.
I, for one, like to keep my installations minimal and I often uninstall
optional (weak) dependencies manually. With Atomic base I wouldn't
be able to modify the base easily on my system(s).
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:21 a.m.
On Tue, Jul 18, 2017 at 7:52 AM, Tom Hughes <tom(a)compton.nu> wrote:
On 18/07/17 14:39, Chris Murphy wrote:
>
> On Tue, Jul 18, 2017 at 5:23 AM, Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
>
>
>> Could you explain the benefits of Atomic system + few layered RPMs vs. a
>> traditional Fedora installation?
>
>
> The OS itself is versioned and binary identical to any other
> installation with the same version. There is no longer the
> pathological behavior of everyone in effect having different sub
> versions of Fedora because their package versions differ, because they
> caught today's update, or yesterday's, or the before noon update, or
> the one with the moon transitioning from crescent to gibbous.
So what is the user experience of "updating" in this world? How does the
transition from one snapshot to the next occur?
That's a matter of policy that has to be worked out, and more than one
policy is possible depending on contributions to make for a sane
UI/UX. But under the hood the way it works with atomic host right
now, it's a CLI interaction with rpm-ostree upgrade (and other
subcommands like deploy, rebase, rollback).
The update happens out of band in its own tree, so there's no such
thing as yanking running binaries out from under a running system, and
no compulsory reboot. It means there's no longer a reboot to get into
the offline update mode, and then yet another reboot to use the
updated system. When you do reboot, you get a GRUB menu that has the
subversioned Fedora, e.g. Fedora 26.38 listed first and default and
Fedora 26.21 as the prior tree you were running. Like everything else,
the kernel version is baked into the subversion (some subversions may
not have upgraded the kernel).
My expectation in Gnome Software is it'll look a lot like it does now,
a split out OS update which you can click on and see a list of
binaries that are being updated and to what versions.
> Also, how to copy / push such apps to workstations. We're
going on 18
> years since .app bundles on macOS can be drag and drop copied to
> install, and it's like, really no one has copied this? The easiest way
> to put a second copy on another machine is to just download it again?
> That's silly.
Well macOS stole "app as a directory" from RISC OS which pushes the idea
back about 30 years ;-)
OK fine, but we should steal that. But this is not the biggest hill to
fight over. That flatpak consolidates applications to their own turf
and prevents them from sneezing all over the OS turf is really super.
--
Chris Murphy
9:59 a.m.
Tom Hughes (tom(a)compton.nu) said:
> On a more general note I think a lot of people are assuming
we're all
> horrible evil people, trying to subvert the One True Fedora Way. This
> is exceptionally poisonous and needs to stop, otherwise Fedora should
> to drop both the "Friends", "Features" and the "First"
in its motto.
I'm not necessarily concerned about subverting (or "changing" as I would
prefer to think of it) the One True Fedora Way, if there are good reasons to
do so and it improves things.
I'm more concerned that there will no longer be One True Fedora Way.
By which I mean that there will no longer be one way to update a Fedora
system because workstations and servers have to be managed in completely
different ways.
In other words that it's no longer possible to use clusterssh to run "dnf
update" on twenty machines at once because each one is now a special
snowflake that requires it's own approach to updating things - possibly even
a mix of approaches if a developer's workstation needs "server updates" to
update postgres and apache and "workstation updates" to update gcc and
firefox.
Why clusterssh when you can Ansible? But I digress.
This situation already exists, though - each of these systems are already
snowflakes if they're user-maintained:
- some apps installed via RPMs connected to Fedora repos
- some from COPRS
- some from Random RPM Downloaded From Third-Party Website
- some from npm/pip
- containers from arbitrary registries.
- curlsh stuff
- things built from source
If the only answer Fedora has for this is "convince everyone to only build
RPMs using system reo components"... that's fighting a rear-guard battle
that has already been lost. I don't think supporting Flatpak apps is
necessarily any worse than what already has to happen with all of the above.
Bill
10:02 a.m.
On Tue, Jul 18, 2017 at 8:06 AM, Tom Hughes <tom(a)compton.nu> wrote:
On 18/07/17 14:55, Richard Hughes wrote:
>
> On 18 July 2017 at 14:52, Tom Hughes <tom(a)compton.nu> wrote:
>>
>> So what is the user experience of "updating" in this world? How does
the
>> transition from one snapshot to the next occur?
>
>
> Basically the same as now. Kalev added a gnome-software plugin that
> downloads the new data, shows the OS update in gnome-software updates
> panel and then you reboot, and it applies the update atomically. You
> reboot, and you're in the new OS.
Any answer that ends in "then you reboot" has instantly failed ;-)
I know you want us to reboot on every update but in the real world nobody is
doing that because it's insane.
Be careful what you ask for. I am a purveyor in ad hominem attacks
once it is obvious a discussion is no longer about technical
arguments, but about the foolish, ignorant, and stubborn bag of mostly
water. And that's because this has been explained on a technical level
many times, why and when the reboot is necessary.
As a kind courtesy refresher course for those with short term memories:
If the real world is just Fedora, the vast majority of Workstation
users update with Gnome Software, and these are offline updates which
require *two* reboots. If it's all of Linux, most people are likewise
doing reboots on updates. And if you go with, you know, the actual
real world where it's 95% Windows and macOS, that's now 100% of users
are doing one or two reboots on an OS update.
What happens on Fedora now, because applications are merged with the
OS, there are application updates that end up making some unnecessary
reboots compulsory. But with atomic + flatpak installations, there is
much better separation of when reboots are necessary. OS updates don't
need to happen as often, and only one reboot is needed, there no
longer a long monolithic offline update process during which time the
system can't be used. Applications can be separately updated, you
don't have to reboot and I'm pretty sure you don't even have to quit
the application during the update. Just quit and relaunch whenever,
and now you're using the new version.
This is way better than what anyone else on any platform is doing,
including even macOS where thus far they don't have OS update
rollbacks (but they do have separate OS and application updates where
application updates don't require reboots).
If you really want us to do that then the thing to spend your time on
is
ways to preserve desktop state across reboots. And yes I know that is
really, really hard which is why every attempt to do so has always been
abandoned. Nobody wants to have to resetup their desktop every day though
which is why we all just run dnf update and cope with the rare occasions
when an app crashes and we have to restart it.
I think it's a completely legitimate gripe that there's neither
desktop nor application state saving. Whether it's day to day work, or
recovering from a DE crash (rare, but more common than needing a
rollback from an OS upgrade), and effectively the lack of hibernation
support, this is definitely a weak area: every platform does this
better, iOS, Android, Windows, macOS. And then on Linux, at least SUSE
and Ubuntu explicitly support hibernation although I have no idea to
what degree they go bug hunting. Fedora definitely does not support it
(meaning it's not configured out of the box, and if it doesn't work
it's not a release blocking bug).
--
Chris Murphy
10:14 a.m.
On Tue, Jul 18, 2017 at 8:04 AM, Tom Hughes <tom(a)compton.nu> wrote:
I'm not necessarily concerned about subverting (or
"changing" as I would
prefer to think of it) the One True Fedora Way, if there are good reasons to
do so and it improves things.
I don't know what you mean by One True Fedora Way. Sounds like mythology to me.
By which I mean that there will no longer be one way to update a
Fedora
system because workstations and servers have to be managed in completely
different ways.
No, with modularity and layering, my expectation is all the products
will be managed the same in this regard.
In other words that it's no longer possible to use clusterssh to run "dnf
update" on twenty machines at once because each one is now a special
snowflake that requires it's own approach to updating things - possibly even
a mix of approaches if a developer's workstation needs "server updates" to
update postgres and apache and "workstation updates" to update gcc and
firefox.
There will be a higher level updating command that will permit you to
do updates across all the layers in one whack, as you describe here.
And there will be probably more than one way for admins to do OS
updates requiring reboots independently of application updates which
don't require reboots. If anything you will have more granular
control, rather than less. But there will also be much greater
consistency among those updated machines.
--
Chris Murphy
10:15 a.m.
On Tue, 2017-07-18 at 15:25 +0200, Dominik 'Rathann' Mierzejewski
wrote:
On Tuesday, 18 July 2017 at 13:39, Mathieu Bridon wrote:
> On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski
> wrote:
> > By the way, I can't figure out how to look inside a Flatpak and
> > review its contents. Could someone provide some pointers?
>
> On the repo all you have is an object store (much like Git's
> .git/objects/ folder), but if you install the app you will also get
> a
> checkout:
>
> $ ls
> ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/
> bin lib manifest.json share
>
> (that's because I installed the app with --user, if you install it
> system-wide then it's under /var/lib/flatpak/app/...)
>
> The manifest.json file is a recipe for how the app was built (like
> a
> spec file), which helps reproducing builds.
>
> The contents of that files/ directory are what gets mounted as
> /app/ in
> the sandbox.
In other words, it's not possible to inspect a binary flatpak without
installing it. With RPMs, I can check what files will land on my
system and where, and also see what the scriptlets do. I can also
extract and inspect individual files. Am I missing something and
worrying unnecessarily that I can't do the same with flatpaks?
Well, the nice thing is that:
- There are no scriplets with Flaptaks - no arbitrary code execution
at install time.
- There is no ability for Flatpaks to drop arbitrary files at
arbitrary locations on your system.
The idea is that you don't *have* to inspect a flatpak before
installation to make sure that it's not dangerous.
That being said, we definitely should have well documented, easy to use
tooling, for downloading, copying, and manipulating Flatpaks without
installing them. You can get it done, but you need to know quite a bit
about ostree.
The 'skopeo' tool from Project Atomic may be the right place for that
type of manipulation - it already has a lot of the right pieces.
Owen
10:28 a.m.
On Tue, Jul 18, 2017 at 8:19 AM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Tuesday, 18 July 2017 at 15:39, Chris Murphy wrote:
> On Tue, Jul 18, 2017 at 5:23 AM, Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
>
>
> > Could you explain the benefits of Atomic system + few layered RPMs vs. a
> > traditional Fedora installation?
>
> The OS itself is versioned and binary identical to any other
> installation with the same version. There is no longer the
> pathological behavior of everyone in effect having different sub
> versions of Fedora because their package versions differ, because they
> caught today's update, or yesterday's, or the before noon update, or
> the one with the moon transitioning from crescent to gibbous.
"One size fits everyone" approach can be dangerous. It never does, in
fact, fit everyone, and often sacrifices flexibility and resource usage
for the convenience of a single image.
I, for one, like to keep my installations minimal and I often uninstall
optional (weak) dependencies manually. With Atomic base I wouldn't
be able to modify the base easily on my system(s).
It's a layered approach. rpm-ostree does let you unlock the base and
install and remove RPMs. You could also run the server side component
that turns RPMs into ostrees yourself (locally or in cloud) and have
however many trees you want, and establish your own rebase policy for
your workstations.
--
Chris Murphy
11:45 a.m.
I think this email from Owen summarizes what we need to keep in mind here.
Containers have caught on due to solving some important problems and thus
people are looking at models for what the future operating system would look
like where containers are the primary content delivery mechanism. In Fedora we have
efforts arounds Docker/OCI containers and Flatpak containers and we are looking at image
based OS installs with the Atomic and Atomic Workstation effort. The fact that we are
developing stuff like this in Fedora is a good thing as
it means that if it does turn out to be a better model we are well positioned to take
advantage of the shift in the market. And if the scepticism some people have about
containers
turns out to be well founded we still have our RPM based OS to fall back on.
So in the long term maybe we will start only shipping containers, if nothing else that is
a
worthwhile goal for the efforts as it informs the design decisions we take for this like
Project Atomic. But having that as a effort goal and it actually becoming the reality is
two very different things. If the model works really well, yes maybe we at some point
(years)
into the future decide to stop doing RPMS (at least as an end user artifact), but in the
meantime
nobody should feel threatened by the efforts done around containers or modularity.
And who knows maybe the future ends up being a bit of a hybrid, Colin Walters is doing
great
work around rpm-ostree for instance.
Christian
----- Original Message -----
> From: "Owen Taylor" <otaylor(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Sent: Tuesday, July 18, 2017 10:15:12 AM
> Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks
>
> On Tue, 2017-07-18 at 08:35 +0200, nicolas.mailhot(a)laposte.net wrote:
> > > > Even if it eventually succeeds crash-landing it in Fedora while
> > > > half
> > > > the security and management tools are lacking is a great way for
> > > > the
> > > > distribution to get an awful reputation, while others will rip
> > > > the
> > > > fruits of this work some years later.
> > > I'm entirely puzzled about how you think we could possibly land
> > > Flatpak
> > > support in Fedora well integrated with our infrastructure, and our
> > > security and management tools without starting to work on it, which
> > > is
> > > essentially what this change proposal is about
> >
> > Working on it is fine. Improving it is fine. Proposing Fedora-
> > generated Flatpacks outside of Fedora is fine.
>
> If Fedora community members are using Fedora infrastructure to build
> Flatpaks that's really by definition part of the Fedora project, isn't
> it?
>
> > Planning to ship stuff as Flatpack only when basic questions such as
> > inter-component dependencies, automated deployment (kickstarts),
> > actual network and disk use (chromebooks), actual user adoption,
> > actual convenience of the security model, etc are not resolved is
> > not.
>
> I think it's important to think ahead and be transparent about what we
> are thinking about, so in that sense we're "planning" to ship things
> Flatpak only. But I want to be clear that there is no *proposal* on the
> table to ship things Flatpak only, and *no proposed timescale*. And
> there won't be until we know how the tools work out for packagers, how
> Flatpak usage works out for users, and we have a significant body of
> Fedora packages built as Flatpaks to look at things like installed size
> and network usage.
>
> These are things we can only get to by building out the infrastructure
> so that packagers can start trying building Flatpaks and users can
> start trying installing them.
>
> > That's the hard and tedious stuff most people on this list care about
> > and GUI app writers, not a lot. That's the point of no easy return
> > where Flatpack is forced on users be it ready or not.
>
> > There is not a vast amount of trust given past history and the way
> > some Flatpack proponents clearly intend to shaft the methods that
> > built Fedora (and its userbase) to jumpstart something else.
>
> It's perfectly fine to be skeptical, it's perfectly fine to ask hard
> questions about areas you think need more work.
>
> But the only way that we get to something that is an evolution of how
> Fedora currently works, that pays attention to the needs of current
> Fedora users, and builds on the strengths of the Fedora infrastructure
> and the people doing all the work in the Fedora community is to work on
> it within Fedora.
>
> Your earlier mail could definitely be taken to mean that we should go
> off and work on Flatpak elsewhere, and when we have a fully working
> ecosystem elsewhere, and have (on our own, without any engagement)
> fully met all the needs of Fedora users, then we can look at
> integrating that into Fedora. That sounds hard to distinguish from
> ignoring Fedora and starting something else. :-)
>
> Owen
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
1:14 p.m.
/*Chris Murphy*/ wrote on Tue, 18 Jul 2017 09:28:53 -0600:
On Tue, Jul 18, 2017 at 8:19 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
...
>
> "One size fits everyone" approach can be dangerous. It never does, in
> fact, fit everyone, and often sacrifices flexibility and resource usage
> for the convenience of a single image.
>
> I, for one, like to keep my installations minimal and I often uninstall
> optional (weak) dependencies manually. With Atomic base I wouldn't
> be able to modify the base easily on my system(s).
It's a layered approach. rpm-ostree does let you unlock the base and
install and remove RPMs. You could also run the server side component
that turns RPMs into ostrees yourself (locally or in cloud) and have
however many trees you want, and establish your own rebase policy for
your workstations.
But if I've understood correctly, any changes to the base
will be
discarded when you update the base image. right?
1:43 p.m.
On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski
wrote:
On Tuesday, 18 July 2017 at 00:02, Michael Catanzaro wrote:
> On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler <kevin.kofler@chello.
> at>
> wrote:
> > The problem is that the RPMs that go into the Flatpaks are not
> > FHS-
> > compliant, so the RPMs will have to carry some conditionals and
> > be built
> > twice.
>
> Yes, that is true. Some apps will have to be patched for Flatpak,
> and building them as both RPMs and Flatpaks is going to require
> conditionals. So there will be some overhead if we support both.
I think this is unacceptable and a blocker. It didn't work with SCLs
and it won't work with Flatpak, either. Flatpaks must be possible to
build from unmodified RPMs or as part of RPM build process.
I actually don't expect to have many conditionals for Flatpak support
in the spec file. There may need to be fixes - for example, if %files
references /usr/share rather than %{_datadir} - but those fixes should
just work for the main build as well. If Fedora packages just hardcoded
FHS paths, then all the path macros wouldn't be necessary to start
with!
An example of where conditionals may be useful is when a library is
bundled into a Flatpak - the rebuild for the flatpak could skip
building the developer docs because they have complicated build
dependencies (graphviz or whatever.) We'll have to see how frequent
that is as we work through real examples.
Owen
1:58 p.m.
On Tue, Jul 18, 2017 at 12:14 PM, Hedayat Vatankhah
<hedayat.fwd(a)gmail.com> wrote:
/*Chris Murphy*/ wrote on Tue, 18 Jul 2017 09:28:53 -0600:
>
> On Tue, Jul 18, 2017 at 8:19 AM, Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
...
>>
>>
>> "One size fits everyone" approach can be dangerous. It never does, in
>> fact, fit everyone, and often sacrifices flexibility and resource usage
>> for the convenience of a single image.
>>
>> I, for one, like to keep my installations minimal and I often uninstall
>> optional (weak) dependencies manually. With Atomic base I wouldn't
>> be able to modify the base easily on my system(s).
>
> It's a layered approach. rpm-ostree does let you unlock the base and
> install and remove RPMs. You could also run the server side component
> that turns RPMs into ostrees yourself (locally or in cloud) and have
> however many trees you want, and establish your own rebase policy for
> your workstations.
But if I've understood correctly, any changes to the base will be discarded
when you update the base image. right?
I'm not sure what the long term plan is. Right now changes to /usr
(normally read only) is done with overlayfs, with the backing
directories in /var/tmp, and are intended to go away at next reboot. I
think what we'll find with deduplication on the Fedora side, is there
will be a bunch of streams for given products, and you can pick how
big of a base you want. Right now there are a bunch of graphical
applications in the base because they haven't been flatpak'd yet. What
I'm reading is any graphical application will get flatpak'd so they
are separate from the base, and each other. You can update all or you
can update individually or not at all.
--
Chris Murphy
2:41 p.m.
De: "Owen Taylor"
But I want to be clear that there is no *proposal* on the
table to ship things Flatpak only, and *no proposed timescale*. And
there won't be until we know how the tools work out for packagers, how
Flatpak usage works out for users, and we have a significant body of
Fedora packages built as Flatpaks to look at things like installed size
and network usage.
Then I'm glad there is absolutely no plan to preempt flatpack technical assessment by
shipping one or more GNOME apps as flatpack-only, leaving Fedora users for whom flatpack
does not work yet behind, and bypassing distribution consensus processes.
This kind of action would be really divisive¹, especially while simultaneously seeking
Fedora endorsement.
Best regards,
¹ Those shortcuts rarely end well. Even when the missing bits are eventually added, users
have a long memory of being left in the dust because their use-cases are deemed
"wrong" or "uninteresting".
--
Nicolas Mailhot
2:43 p.m.
On Tue, Jul 18, 2017, at 02:58 PM, Chris Murphy wrote:
> But if I've understood correctly, any changes to the base
will be discarded
> when you update the base image. right?
No; `rpm-ostree install` is persistent, and so are other changes like
`rpm-ostree initramfs --enable` and so is the recently added `ex override`:
https://github.com/projectatomic/rpm-ostree/pull/852
A bit more information about layering and live changes:
http://www.projectatomic.io/blog/2017/06/rpm-ostree-v2017.6-released/
What Chris is talking about is `ostree admin unlock` which is *designed*
to go away after reboot:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-M...
I'm not sure what the long term plan is. Right now changes to
/usr
(normally read only)
It's more that rpm-ostree is the *sole* tool that mutates /usr; every
change is an atomic, interrupt-able transaction queued for the next boot
by default (unless one invokes `ex livefs`): Even local RPM installation:
# curl -L -O
https://kojipkgs.fedoraproject.org//packages/cowsay/3.04/5.fc26/noarch/co...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 46398 100 46398 0 0 30583 0 0:00:01 0:00:01 --:--:-- 30565
# rpm-ostree install ./cowsay-3.04-5.fc26.noarch.rpm
...
Will download: 39 packages (13.1 MB)
...
Transaction complete; bootconfig swap: yes deployment count change: 1
Added:
cowsay-3.04-5.fc26.noarch
groff-base-1.22.3-9.fc26.x86_64
perl-4:5.24.2-393.fc26.x86_64
perl-Carp-1.40-366.fc26.noarch
...
# cowsay foo
bash: cowsay: command not found
# rpm-ostree ex livefs
...
Preparing new rollback matching currently booted deployment
Transaction complete; bootconfig swap: yes deployment count change: 1
Overlaying /usr... done
...
# cowsay hi
____
< hi >
----
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
# touch /usr/bin/foo
touch: cannot touch '/usr/bin/foo': Read-only file system
(How did it work if /usr stays read-only the entire time? It's because rpm-ostree
knows how to go
"underneath" the mount, which really comes from /sysroot)
Big picture, as it says on github, rpm-ostree aims to be a full
hybrid image/package system, also supporting both offline updates
*and* online updates if you want that - anything that is "you can't do
that"
is a bug.
3 p.m.
On Tue, Jul 18, 2017 at 09:41:30PM +0200, nicolas.mailhot(a)laposte.net wrote:
Then I'm glad there is absolutely no plan to preempt flatpack
technical assessment by shipping one or more GNOME apps as
flatpack-only, leaving Fedora users for whom flatpack does not work
yet behind, and bypassing distribution consensus processes.
Please tone this inflammatory rhetoric down. It's not helpful. When you
said you wanted this part of the thread to close, I thought that's what
you meant and took it seriously.
Here, I assume you're talking about no one having packaged GNOME
Recipies (apparently _written_ as a Flatpak proof of concept) in
traditional RPM form. But, we can't make *any* upstream author package
their stuff in RPM for us.
But, if you want that as an RPM in Fedora, _no one is really stopping
you_. Go for it!
If you're talking about something else here, then I missed it
completely and encourage you to be more straightforward and stick to
the technical.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:01 p.m.
On Tue, Jul 18, 2017 at 3:41 PM, <nicolas.mailhot(a)laposte.net> wrote:
De: "Owen Taylor"
> But I want to be clear that there is no *proposal* on the
> table to ship things Flatpak only, and *no proposed timescale*. And
> there won't be until we know how the tools work out for packagers, how
> Flatpak usage works out for users, and we have a significant body of
> Fedora packages built as Flatpaks to look at things like installed size
> and network usage.
Then I'm glad there is absolutely no plan to preempt flatpack technical assessment by
shipping one or more GNOME apps as flatpack-only, leaving Fedora users for whom flatpack
does not work yet behind, and bypassing distribution consensus processes.
This kind of action would be really divisive¹, especially while simultaneously seeking
Fedora endorsement.
Best regards,
¹ Those shortcuts rarely end well. Even when the missing bits are eventually added, users
have a long memory of being left in the dust because their use-cases are deemed
"wrong" or "uninteresting".
I think this already happened. Applications like GNOME Recipes are
only available via Flatpaks. The Workstation WG did not package it for
Fedora 26. I don't know if other GNOME applications are in a similar state. :(
--
真実はいつも一つ！/ Always, there's only one truth!
3:03 p.m.
On Tue, Jul 18, 2017 at 4:00 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Jul 18, 2017 at 09:41:30PM +0200, nicolas.mailhot(a)laposte.net
wrote:
> Then I'm glad there is absolutely no plan to preempt flatpack
> technical assessment by shipping one or more GNOME apps as
> flatpack-only, leaving Fedora users for whom flatpack does not work
> yet behind, and bypassing distribution consensus processes.
Please tone this inflammatory rhetoric down. It's not helpful. When you
said you wanted this part of the thread to close, I thought that's what
you meant and took it seriously.
Here, I assume you're talking about no one having packaged GNOME
Recipies (apparently _written_ as a Flatpak proof of concept) in
traditional RPM form. But, we can't make *any* upstream author package
their stuff in RPM for us.
But, if you want that as an RPM in Fedora, _no one is really stopping
you_. Go for it!
If you're talking about something else here, then I missed it
completely and encourage you to be more straightforward and stick to
the technical.
I think he's worried that applications might intentionally get left
behind that someone would want.
Also, GNOME upstream doesn't do the packaging for Fedora GNOME anyway.
That's the Workstation WG's job. Just like how the KDE SIG packages
the Qt/KDE stack, the Workstation WG (aka GNOME SIG) does this for the
GTK+/GNOME stack.
--
真実はいつも一つ！/ Always, there's only one truth!
3:05 p.m.
On Tue, 2017-07-18 at 21:41 +0200, nicolas.mailhot(a)laposte.net wrote:
De: "Owen Taylor"
> But I want to be clear that there is no *proposal* on the
> table to ship things Flatpak only, and *no proposed timescale*. And
> there won't be until we know how the tools work out for packagers,
> how
> Flatpak usage works out for users, and we have a significant body
> of
> Fedora packages built as Flatpaks to look at things like installed
> size
> and network usage.
Then I'm glad there is absolutely no plan to preempt flatpack
technical assessment by shipping one or more GNOME apps as flatpack-
only, leaving Fedora users for whom flatpack does not work yet
behind, and bypassing distribution consensus processes.
Matthias Clasen, spare-time upstream GNOME Developer, wrote an
application, largely to see for himself what the upstream developer
experience was for writing an application to be sandboxed using
Flatpak portals, and what the upstream developer experience is
distributing code to users as a Flatpak.
It's not entirely unsurprising that Matthias Clasen, Fedora
Contributor, was not particularly interested in packaging that non-
sandboxed, not as a Flatpak, nor that Matthias Clasen, manager of a
portion of the Red Hat desktop team, didn't find it a priority to
assign someone to do it.
While I think it's a bit unfriendly to distribute code that someone
intended to be a test case and showcase for Flatpaks as a non-Flatpak,
I don't think there's anything in the Fedora guidelines that would
prevent someone else from submitting that package.
But maybe it would be more useful to try it out the Flatpak and see
what the experience is like, and what needs to be improved? [*]
In other words, GNOME Recipes is a special case, not some declaration
that we're never going to package any new GNOME application as a
Flatpak again.
Owen
[*] Note that the stable Flatpak of GNOME Recipes is huge, not because
it's a Flatpak, but because it contains all the images from all the
recipes. This is fixed in the nightly version, which downloads images
on demand.
3:07 p.m.
On Tue, Jul 18, 2017 at 04:00:10PM -0400, Matthew Miller wrote:
On Tue, Jul 18, 2017 at 09:41:30PM +0200, nicolas.mailhot(a)laposte.net
wrote:
> Then I'm glad there is absolutely no plan to preempt flatpack
> technical assessment by shipping one or more GNOME apps as
> flatpack-only, leaving Fedora users for whom flatpack does not work
> yet behind, and bypassing distribution consensus processes.
Please tone this inflammatory rhetoric down. It's not helpful. When you
said you wanted this part of the thread to close, I thought that's what
you meant and took it seriously.
Matthew, as FPL I think you also shouldn't take sides here. There's a
lot of inflamatory rhetoric in this thread, and it's my opinion that
you've sided with what I'd call the "GNOME/Flatpak" camp, and ignored
some inflamatory (and incorrect) statements they have made, which
Kevin (to his credit) did not take the bait and respond to.
Just my 2p, and I'll say no more.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
3:18 p.m.
On Tue, Jul 18, 2017 at 09:07:28PM +0100, Richard W.M. Jones wrote:
Matthew, as FPL I think you also shouldn't take sides here.
There's a
lot of inflamatory rhetoric in this thread, and it's my opinion that
you've sided with what I'd call the "GNOME/Flatpak" camp, and ignored
some inflamatory (and incorrect) statements they have made, which
Kevin (to his credit) did not take the bait and respond to.
I don't intend to take sides. I expect everyone involved to keep to a
high standard. I'm sorry if I missed something I should have responded
to. I actually hope that some sidetracks aside, we don't actually have
"camps" here and that everyone is on the *same* side wanting to make
Fedora better.
I *do* have a bias towards "hey, let's try stuff out" and I *do* think
this particular thing is interesting. But I also hope that that's
hardly a "camp" within Fedora, as it is something we've long listed as
one of our basic foundations.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:59 p.m.
>>>> "OT" == Owen Taylor
<otaylor(a)redhat.com> writes:
OT> If Fedora packages just hardcoded FHS paths, then all the path
OT> macros wouldn't be necessary to start with!
Actually we've been making those really annoying macros more and more
optional over time. The only one which is mandatory is %_libdir. I
personally never use them in any of my packaging unless they save
typing. It's not as if we're going to suddenly relocate /var, and there
is just no way I'm using %_localstatedir when /var is easier to type and
far more explicit.
- J<
4:01 p.m.
De: "Owen Taylor"
But maybe it would be more useful to try it out the Flatpak and see
what the experience is like, and what needs to be improved? [*]
I probably would if the resource profile was compatible with this chromebook storage
capabilities. As it is I'm not too keen on having system and apps overflow to the sd
card I use (and switch) for personal data.
Which is probably one reason I'm less than enthusiastic about moving to flatpack. Or
about having competing software mamagement tools that "just" need their own
duplicated storage space. I suppose I should revisit wayland remoting, to check if it got
to the point streaming individual gui apps from the dlna box is sensible.
Cheers,
--
Nicola Mailhot
9:44 p.m.
On Fri, Jul 14, 2017 at 12:59 PM, Debarshi Ray <rishi.is(a)lostca.se> wrote:
On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > F29: packagers (of graphical applications) must create Flatpaks of
> > their applications if possible. They *may* keep standard RPM
> > packaging.
>
> At least we see where this is going.
>
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks? Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
By putting them in "/opt", the way other sanely packaged 3rd party
components do?
4:12 a.m.
Neal Gompa píše v Út 18. 07. 2017 v 16:03 -0400:
On Tue, Jul 18, 2017 at 4:00 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Tue, Jul 18, 2017 at 09:41:30PM +0200, nicolas.mailhot(a)laposte.n
> et wrote:
> > Then I'm glad there is absolutely no plan to preempt flatpack
> > technical assessment by shipping one or more GNOME apps as
> > flatpack-only, leaving Fedora users for whom flatpack does not
> > work
> > yet behind, and bypassing distribution consensus processes.
>
> Please tone this inflammatory rhetoric down. It's not helpful. When
> you
> said you wanted this part of the thread to close, I thought that's
> what
> you meant and took it seriously.
>
> Here, I assume you're talking about no one having packaged GNOME
> Recipies (apparently _written_ as a Flatpak proof of concept) in
> traditional RPM form. But, we can't make *any* upstream author
> package
> their stuff in RPM for us.
>
> But, if you want that as an RPM in Fedora, _no one is really
> stopping
> you_. Go for it!
>
> If you're talking about something else here, then I missed it
> completely and encourage you to be more straightforward and stick
> to
> the technical.
>
I think he's worried that applications might intentionally get left
behind that someone would want.
Also, GNOME upstream doesn't do the packaging for Fedora GNOME
anyway.
That's the Workstation WG's job. Just like how the KDE SIG packages
the Qt/KDE stack, the Workstation WG (aka GNOME SIG) does this for
the
GTK+/GNOME stack.
I don't think this is entirely true.
The mission statement of Workstation Working Group:
"The Fedora Workstation working group aims to create a reliable, user-
friendly and powerful operating system for laptops and PC hardware. The
system will primarily be aimed at providing a platform for development
of server side and client applications that is attractive to a range of
developers - from hobbyists and students to developers working in
corporate environments."
It's a group that focuses on building a desktop OS based on GNOME, yes,
that involves packaging of a sizable part of the GNOME stack, but that
doesn't mean that it's their job and obligation to package (any) GNOME
software.
Jiri
4:17 a.m.
Nico Kadel-Garcia píše v Út 18. 07. 2017 v 22:44 -0400:
On Fri, Jul 14, 2017 at 12:59 PM, Debarshi Ray
<rishi.is(a)lostca.se>
wrote:
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > F29: packagers (of graphical applications) must create
> > > Flatpaks of
> > > their applications if possible. They *may* keep standard
> > > RPM
> > > packaging.
> >
> > At least we see where this is going.
> >
> > If RPMs of the graphical application work fine now, what on earth
> > is
> > the point of forcing packagers to make Flatpaks? Sandboxing
> > isn't one
> > of them - as already explained, sandboxing is orthogonal to
> > packaging.
>
> Huh? How would you get sandboxing without Flatpaks? Unless you are
> proposing a different sandboxing technology.
By putting them in "/opt", the way other sanely packaged 3rd party
components do?
How does that ensure any sandboxing?
Jiri
5:21 a.m.
On Tuesday, 18 July 2017 at 17:15, Owen Taylor wrote:
On Tue, 2017-07-18 at 15:25 +0200, Dominik 'Rathann'
Mierzejewski
wrote:
> On Tuesday, 18 July 2017 at 13:39, Mathieu Bridon wrote:
> > On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > By the way, I can't figure out how to look inside a Flatpak and
> > > review its contents. Could someone provide some pointers?
> >
> > On the repo all you have is an object store (much like Git's
> > .git/objects/ folder), but if you install the app you will also get
> > a
> > checkout:
> >
> > $ ls
> > ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/
> > bin lib manifest.json share
> >
> > (that's because I installed the app with --user, if you install it
> > system-wide then it's under /var/lib/flatpak/app/...)
> >
> > The manifest.json file is a recipe for how the app was built (like
> > a
> > spec file), which helps reproducing builds.
> >
> > The contents of that files/ directory are what gets mounted as
> > /app/ in
> > the sandbox.
>
> In other words, it's not possible to inspect a binary flatpak without
> installing it. With RPMs, I can check what files will land on my
> system and where, and also see what the scriptlets do. I can also
> extract and inspect individual files. Am I missing something and
> worrying unnecessarily that I can't do the same with flatpaks?
Well, the nice thing is that:
- There are no scriplets with Flaptaks - no arbitrary code execution
at install time.
- There is no ability for Flatpaks to drop arbitrary files at
arbitrary locations on your system.
That is good to know, assuming there are no bugs that can be exploited
by evil flatpak creator to do just that. ;) At least with RPM, we *know*
it's possible by design.
The files themselves are still arbitrary, even if the locations aren't.
How do I know where their files will land?
The idea is that you don't *have* to inspect a flatpak before
installation to make sure that it's not dangerous.
I don't *have* to inspect an RPM (coming from Fedora), either, but I sure
like having that ability.
That being said, we definitely should have well documented, easy to
use
tooling, for downloading, copying, and manipulating Flatpaks without
installing them. You can get it done, but you need to know quite a bit
about ostree.
The 'skopeo' tool from Project Atomic may be the right place for that
type of manipulation - it already has a lot of the right pieces.
Another thing: RPM has the ability to run queries (-qp) against remote
package files exactly the same as for local ones. I don't see an option
to do the same with flatpak without adding a remote repo and installing
it first:
$ flatpak info
"https://git.gnome.org/browse/gnome-apps-nightly/plain/gnome-weather.flatpakref?h=stable"
error: Invalid id https:: Name can't contain :
$ flatpak --user remote-add gnome https://sdk.gnome.org/gnome.flatpakrepo
$ flatpak --user remote-add gnome-apps https://sdk.gnome.org/gnome-apps.flatpakrepo
$ flatpak info org.gnome.Weather
error: org.gnome.Weather master not installed
$ flatpak remotes
Name Options
gnome user
gnome-apps user
$ flatpak remote-ls gnome-apps
error: Remote "gnome-apps" not found
Now that's confusing. It shows me configured remotes, but then says
they're not found. Shall I file a bug?
Even after installation, I don't get a file manifest:
$ flatpak -o -s -m -e -v info org.gnome.Weather
XA: No installations directory in /etc/flatpak/installations.d. Skipping
gnome-apps 10.5 MB
[Application]
name=org.gnome.Weather
runtime=org.gnome.Platform/x86_64/3.24
sdk=org.gnome.Sdk/x86_64/3.24
command=/app/share/org.gnome.Weather/org.gnome.Weather.Application
[Context]
shared=network;ipc;
sockets=x11;wayland;
filesystems=xdg-run/dconf;~/.config/dconf:ro;
[Session Bus Policy]
ca.desrt.dconf=talk
[System Bus Policy]
org.freedesktop.GeoClue2=talk
[Environment]
DCONF_USER_CONFIG_DIR=.config/dconf
[Extension org.gnome.Weather.Locale]
directory=share/runtime/locale
autodelete=true
[Extension org.gnome.Weather.Debug]
directory=lib/debug
autodelete=true
no-autodownload=true
Extension: runtime/org.gnome.Weather.Locale/x86_64/stable
ID: org.gnome.Weather.Locale
Origin: gnome-apps
Commit: 4e39959a470f1e8a77f22bd57e91fc268a09f3fc7b894c3c50dfa8f28c618585
Installed size: <512 bytes
Subpaths: /en
Another thing that surprised me: libgnomedesktop doesn't seem to be part
of org.gnome.Platform runtime and is bundled with the application
instead:
$ ls -l
.local/share/flatpak/app/org.gnome.Weather/x86_64/stable/cd5dad9f9fa301cfc8ee6cdd42985294461a2b50f79ff5ea0f142ae88f571196/files/lib/libgnome-desktop-3.so.12.2.0
-rwxr-xr-x. 2 rathann rathann 232984 Jan 1 1970
.local/share/flatpak/app/org.gnome.Weather/x86_64/stable/cd5dad9f9fa301cfc8ee6cdd42985294461a2b50f79ff5ea0f142ae88f571196/files/lib/libgnome-desktop-3.so.12.2.0
$ ls -l
.local/share/flatpak/runtime/org.gnome.Platform/x86_64/3.24/917abdce38d8852606b5ad7311052cdbd083b223f8c39d8567880b23af3c3e52/files/lib/libgnome*
ls: cannot access
'.local/share/flatpak/runtime/org.gnome.Platform/x86_64/3.24/917abdce38d8852606b5ad7311052cdbd083b223f8c39d8567880b23af3c3e52/files/lib/libgnome*':
No such file or directory
(What's wrong with the file timestamp, by the way?)
And... another:
$ flatpak list
Ref Options
org.gnome.Weather/x86_64/stable user,current
org.gnome.Platform/x86_64/3.24 user,runtime
$ flatpak uninstall org.gnome.Platform/x86_64/3.24
error: org.gnome.Platform 3.24 not installed
(Again, huh?)
$ flatpak --user uninstall org.gnome.Platform/x86_64/3.24
Uninstalling org.gnome.Platform/x86_64/3.24
Uninstalling org.gnome.Platform.Locale/x86_64/3.24
WTF? Dependencies, anyone?
And yes, I'll go and file bugs, but these are basic things and I can't
imagine why they weren't noticed and fixed before. Flatpak has been
available in Fedora for over a year now. If it wants to be a serious
contender as an application distribution mechanism, it has to do much
better than that.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:25 a.m.
De: "Jiří Eischmann"
It's a group that focuses on building a desktop OS based on
GNOME, yes,
that involves packaging of a sizable part of the GNOME stack, but that
doesn't mean that it's their job and obligation to package (any) GNOME
software.
Sure, but they can't have it both ways: be part of Fedora when they need support,
resources, testers and endorsement, and independent project that owes nothing to anyone
when it's time to integrate their stuff in Fedora or just listen to Fedora users. That
duality can only breed conflicts.
And I am *not* accusing Owen to plan such a thing but the proposal carries this risk.
Cheers,
--
Nicolas Mailhot
5:47 a.m.
On Wednesday, 19 July 2017 at 12:21, Dominik 'Rathann' Mierzejewski wrote:
[...]
$ flatpak remotes
Name Options
gnome user
gnome-apps user
$ flatpak remote-ls gnome-apps
error: Remote "gnome-apps" not found
Now that's confusing. It shows me configured remotes, but then says
they're not found. Shall I file a bug?
This is already reported: https://github.com/flatpak/flatpak/issues/282 .
[...]
Another thing that surprised me: libgnomedesktop doesn't seem to
be part
of org.gnome.Platform runtime and is bundled with the application
instead:
$ ls -l
.local/share/flatpak/app/org.gnome.Weather/x86_64/stable/cd5dad9f9fa301cfc8ee6cdd42985294461a2b50f79ff5ea0f142ae88f571196/files/lib/libgnome-desktop-3.so.12.2.0
-rwxr-xr-x. 2 rathann rathann 232984 Jan 1 1970
.local/share/flatpak/app/org.gnome.Weather/x86_64/stable/cd5dad9f9fa301cfc8ee6cdd42985294461a2b50f79ff5ea0f142ae88f571196/files/lib/libgnome-desktop-3.so.12.2.0
$ ls -l
.local/share/flatpak/runtime/org.gnome.Platform/x86_64/3.24/917abdce38d8852606b5ad7311052cdbd083b223f8c39d8567880b23af3c3e52/files/lib/libgnome*
ls: cannot access
'.local/share/flatpak/runtime/org.gnome.Platform/x86_64/3.24/917abdce38d8852606b5ad7311052cdbd083b223f8c39d8567880b23af3c3e52/files/lib/libgnome*':
No such file or directory
(What's wrong with the file timestamp, by the way?)
Reported: https://github.com/flatpak/flatpak/issues/926 .
And... another:
$ flatpak list
Ref Options
org.gnome.Weather/x86_64/stable user,current
org.gnome.Platform/x86_64/3.24 user,runtime
$ flatpak uninstall org.gnome.Platform/x86_64/3.24
error: org.gnome.Platform 3.24 not installed
(Again, huh?)
$ flatpak --user uninstall org.gnome.Platform/x86_64/3.24
Uninstalling org.gnome.Platform/x86_64/3.24
Uninstalling org.gnome.Platform.Locale/x86_64/3.24
WTF? Dependencies, anyone?
This is now https://github.com/flatpak/flatpak/issues/925 .
Another missing feature: no easy-to-use `rpm -V` equivalent:
https://github.com/flatpak/flatpak/issues/532
and that's only for integrity verification. How do I check if all
dependencies are installed correctly?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:51 a.m.
On Tuesday, 18 July 2017 at 21:43, Colin Walters wrote:
On Tue, Jul 18, 2017, at 02:58 PM, Chris Murphy wrote:
> > But if I've understood correctly, any changes to the base will be
discarded
> > when you update the base image. right?
No; `rpm-ostree install` is persistent, and so are other changes like
`rpm-ostree initramfs --enable` and so is the recently added `ex override`:
https://github.com/projectatomic/rpm-ostree/pull/852
A bit more information about layering and live changes:
http://www.projectatomic.io/blog/2017/06/rpm-ostree-v2017.6-released/
What Chris is talking about is `ostree admin unlock` which is *designed*
to go away after reboot:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-M...
> I'm not sure what the long term plan is. Right now changes to /usr
> (normally read only)
It's more that rpm-ostree is the *sole* tool that mutates /usr; every
change is an atomic, interrupt-able transaction queued for the next boot
by default (unless one invokes `ex livefs`): Even local RPM installation:
[...]
(How did it work if /usr stays read-only the entire time? It's
because rpm-ostree knows how to go
"underneath" the mount, which really comes from /sysroot)
Big picture, as it says on github, rpm-ostree aims to be a full
hybrid image/package system, also supporting both offline updates
*and* online updates if you want that - anything that is "you can't do
that"
is a bug.
This is very cool! Is this documented somewhere public? If not, it'd
make a great Fedora Magazine article. Please write one!
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:56 a.m.
On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote:
[...]
An example of where conditionals may be useful is when a library is
bundled into a Flatpak - the rebuild for the flatpak could skip
building the developer docs because they have complicated build
dependencies (graphviz or whatever.) We'll have to see how frequent
that is as we work through real examples.
The bundling thing is what I'm afraid of. If we don't make it a
requirement or at least a strong recommendation to unbundle libraries
from Flatpaks, then we'll end up with Android app store-like
ecosystem, where everyone bundles everything which is not in one of the
runtimes and even runtimes duplicate libraries between each other,
because it's easy and not forbidden. And since there's no easy way
to track bundled stuff inside Flatpaks, we're much worse off than
where we are with RPM packages currently.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6 a.m.
On Tuesday, 18 July 2017 at 22:01, Neal Gompa wrote:
On Tue, Jul 18, 2017 at 3:41 PM, <nicolas.mailhot(a)laposte.net>
wrote:
[...]
> Then I'm glad there is absolutely no plan to preempt
flatpack technical
> assessment by shipping one or more GNOME apps as flatpack-only, leaving
> Fedora users for whom flatpack does not work yet behind, and bypassing
> distribution consensus processes.
>
> This kind of action would be really divisive¹, especially while
> simultaneously seeking Fedora endorsement.
[...]
> ¹ Those shortcuts rarely end well. Even when the missing bits
are
> eventually added, users have a long memory of being left in the dust
> because their use-cases are deemed "wrong" or "uninteresting".
I think this already happened. Applications like GNOME Recipes are
only available via Flatpaks. The Workstation WG did not package it for
Fedora 26. I don't know if other GNOME applications are in a similar state. :(
It's not shipped as Flatpak by Fedora. Nobody's stopping you from submitting
a package of Recipes for review. Or are you demanding that the Workstation
WG maintain an RPM package of Recipes?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6:28 a.m.
On 19 July 2017 at 11:56, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
And since there's no easy way
to track bundled stuff inside Flatpaks, we're much worse off than
where we are with RPM packages currently.
I'm getting somewhat sick of the hyperbole, but I'm wondering if
you're aware of
/var/lib/flatpak/app/org.gnome.Recipes/x86_64/master/active/files/manifest.json
Richard.
7:13 a.m.
On Wednesday, 19 July 2017 at 13:28, Richard Hughes wrote:
On 19 July 2017 at 11:56, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
> And since there's no easy way
> to track bundled stuff inside Flatpaks, we're much worse off than
> where we are with RPM packages currently.
I'm getting somewhat sick of the hyperbole, but I'm wondering if
you're aware of
/var/lib/flatpak/app/org.gnome.Recipes/x86_64/master/active/files/manifest.json
It doesn't contain a separate "version" tag for each bundled component,
so it's barely useful. One would need to parse the "url" tags for
version numbers. So, I stand by my words: no easy way to track bundled
stuff.
Can such "modules" dependencies be satisfied with components from
a(nother) runtime, assuming their sha256 hashes are the same? And by
"satisfied" I mean that they won't be downloaded from the repo when
installing an application with such deps and will be deleted from
existing applications if they appear in any installed runtime after an
update.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:16 a.m.
On 07/17/2017 08:44 PM, Kevin Kofler wrote:
Dusty Mabe wrote:
> I'm sure some people are aware but for those who aren't it is worth noting
> that we have an entire edition (atomic host) that is built around atomic
> updates for rpm content.
Atomic updates for "rpm content", but not for actual RPMs, unfortunately,
only for blobs composed on the server side from an unchangeable set of RPMs.
So it does not solve the problem at all.
The server side content is something you can't change, but you can easily
create your own server and define that content if you want.
Also you can easily install packages now using `rpm-ostree install foo`.
Which will atomically install rpms (deployment staged for next reboot).
If atomicity is what you want then this will give you that.
http://www.projectatomic.io/blog/2017/04/rpm-ostree-v2017.4-released/
Dusty
10:05 a.m.
On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann' Mierzejewski
wrote:
On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote:
[...]
> An example of where conditionals may be useful is when a library is
> bundled into a Flatpak - the rebuild for the flatpak could skip
> building the developer docs because they have complicated build
> dependencies (graphviz or whatever.) We'll have to see how frequent
> that is as we work through real examples.
The bundling thing is what I'm afraid of. If we don't make it a
requirement or at least a strong recommendation to unbundle libraries
from Flatpaks, then we'll end up with Android app store-like
ecosystem, where everyone bundles everything which is not in one of
the
runtimes and even runtimes duplicate libraries between each other,
because it's easy and not forbidden. And since there's no easy way
to track bundled stuff inside Flatpaks, we're much worse off than
where we are with RPM packages currently.
Bundling enables some of the key features of Flatpak - the ability to
try out new versions of an application even if they require library
versions newer than what you have on your system, the ability to have a
single binary package that can be installed on different Linux
distributions, the assurance that installing an application will never
prevent you from upgrading your operating system due to missing
dependencies, and so forth.
And yes, there are downsides from bundling. But we're trying to address
those downsides as much as possible. Some of that is in the Flatpak
system:
* Runtimes mean that common libraries (libc, X11, etc) and libraries
that often have security updates (image libraries, crypto libraries)
will not be bundled.
* The use of ostree for storage means that if the exact same file is
bundled in two separate Flatpaks, it will be only stored on disk and in
memory once.
And some of that is going to be in how we generate Flatpaks from Fedora
content:
* Bundled libraries will not be arbitrary source code builds, they will
be built from the exact same spec files in dist-git.
* We will track (via the PDC) what versions of what packages are
included in every Flatpak runtime and app we ship, and can
automatically rebuild and update the runtime and apps as needed.
* We will include a manifest of the component RPM versions in each
Flatpak runtime and app.
There are definitely some open questions, and we'll have to pay close
attention to how much duplication we are getting in practice, and look
at whether we need to adjust the composition of the Fedora runtime and
our build methods to reduce duplication, but it's definitely not going
to be a Wild West where every application you install on your system
has its own copy of libz that was downloaded somewhere off the
internet.
Regards,
Owen
10:27 a.m.
On Wednesday, 19 July 2017 at 17:05, Owen Taylor wrote:
On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann'
Mierzejewski
wrote:
> On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote:
> [...]
> > An example of where conditionals may be useful is when a library is
> > bundled into a Flatpak - the rebuild for the flatpak could skip
> > building the developer docs because they have complicated build
> > dependencies (graphviz or whatever.) We'll have to see how frequent
> > that is as we work through real examples.
>
> The bundling thing is what I'm afraid of. If we don't make it a
> requirement or at least a strong recommendation to unbundle libraries
> from Flatpaks, then we'll end up with Android app store-like
> ecosystem, where everyone bundles everything which is not in one of
> the
> runtimes and even runtimes duplicate libraries between each other,
> because it's easy and not forbidden. And since there's no easy way
> to track bundled stuff inside Flatpaks, we're much worse off than
> where we are with RPM packages currently.
Bundling enables some of the key features of Flatpak - the ability to
try out new versions of an application even if they require library
versions newer than what you have on your system, the ability to have a
single binary package that can be installed on different Linux
distributions, the assurance that installing an application will never
prevent you from upgrading your operating system due to missing
dependencies, and so forth.
And yes, there are downsides from bundling. But we're trying to address
those downsides as much as possible. Some of that is in the Flatpak
system:
* Runtimes mean that common libraries (libc, X11, etc) and libraries
that often have security updates (image libraries, crypto libraries)
will not be bundled.
* The use of ostree for storage means that if the exact same file is
bundled in two separate Flatpaks, it will be only stored on disk and in
memory once.
And some of that is going to be in how we generate Flatpaks from Fedora
content:
* Bundled libraries will not be arbitrary source code builds, they will
be built from the exact same spec files in dist-git.
* We will track (via the PDC) what versions of what packages are
What's "PDC"?
included in every Flatpak runtime and app we ship, and can
automatically rebuild and update the runtime and apps as needed.
* We will include a manifest of the component RPM versions in each
Flatpak runtime and app.
There are definitely some open questions, and we'll have to pay close
attention to how much duplication we are getting in practice, and look
at whether we need to adjust the composition of the Fedora runtime and
our build methods to reduce duplication, but it's definitely not going
to be a Wild West where every application you install on your system
has its own copy of libz that was downloaded somewhere off the
internet.
That is excellent. I wish this had been mentioned either on the change
proposal page or early in this thread. Thank you for having thought
this through. If that's the plan, then it should have much less
opposition then you see in this thread.
I still think that this proposal makes more sense for Atomic Workstation
than for a traditional RPM-based Fedora product due to duplication
between Flatpak runtime(s) and installed packages.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
11:48 a.m.
On Wed, Jul 19, 2017 at 12:25:26PM +0200, nicolas.mailhot(a)laposte.net wrote:
Sure, but they can't have it both ways: be part of Fedora when
they
need support, resources, testers and endorsement, and independent
project that owes nothing to anyone when it's time to integrate their
stuff in Fedora or just listen to Fedora users. That duality can only
breed conflicts.
I think having the Workstation WG _actually_ be synonymous with "GNOME
SIG" could lead to that duality. But it's really not meant to be — and
actually partly for *exactly* this reason. The WG should focus on
what's important for that Fedora Edition, and not necessarily whatever
is going on in upstream GNOME. It happens that various people in the WG
are also deeply involved in upstream GNOME and in GNOME in Fedora in
other ways (a fact which largely benefits both communities), but that
shouldn't get confused with work done wearing the Workstation "hat".
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:50 a.m.
On Wed, 2017-07-19 at 17:27 +0200, Dominik 'Rathann' Mierzejewski
wrote:
On Wednesday, 19 July 2017 at 17:05, Owen Taylor wrote:
>
> * Bundled libraries will not be arbitrary source code builds, they
> will
> be built from the exact same spec files in dist-git.
> * We will track (via the PDC) what versions of what packages are
What's "PDC"?
"Product Definition Center" - https://pdc.fedoraproject.org/
> included in every Flatpak runtime and app we ship, and can
> automatically rebuild and update the runtime and apps as needed.
> * We will include a manifest of the component RPM versions in each
> Flatpak runtime and app.
>
> There are definitely some open questions, and we'll have to pay
> close attention to how much duplication we are getting in practice,
> and look at whether we need to adjust the composition of the Fedora
> runtime and our build methods to reduce duplication, but it's
> definitely not going to be a Wild West where every application you
> install on your system has its own copy of libz that was downloaded
> somewhere off the internet.
That is excellent. I wish this had been mentioned either on the
change proposal page or early in this thread. Thank you for having
thought this through. If that's the plan, then it should have much
less opposition then you see in this thread.
I'll think about ways to make this information more explicit in the
proposal. Thanks for the feedback!
I still think that this proposal makes more sense for Atomic
Workstation than for a traditional RPM-based Fedora product due to
duplication between Flatpak runtime(s) and installed packages.
Well, certainly one big reason we're working on this is that we want to
have applications available to people trying out Atomic Workstation!
While there are real advantages to Flatpaks on top of a traditional
install as well, in the near term, most people running in that mode
will still have most of their applications installed as RPMs.
Owen
11:52 a.m.
On Wed, Jul 19, 2017 at 05:27:17PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> * We will track (via the PDC) what versions of what packages
are
What's "PDC"?
Part of Fedora Infrastructure:
https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:44 p.m.
Bill Nottingham wrote:
This situation already exists, though - each of these systems are
already
snowflakes if they're user-maintained:
- some apps installed via RPMs connected to Fedora repos
- some from COPRS
- some from Random RPM Downloaded From Third-Party Website
- some from npm/pip
- containers from arbitrary registries.
- curlsh stuff
- things built from source
The right solution if you have such a mess is to build RPMs of the software,
and if possible, to get them into Fedora proper. That is what we need to
spend our time on, not on adding yet another competing technology to this
mess, which will only make it worse.
If the only answer Fedora has for this is "convince everyone to
only build
RPMs using system reo components"... that's fighting a rear-guard battle
that has already been lost. I don't think supporting Flatpak apps is
necessarily any worse than what already has to happen with all of the
above.
I don't agree at all that this battle is already lost. I have a lot of
software on my systems and almost all of it is from RPMs. That's how I can
manage it. Non-RPM software is always a PITA.
Kevin Kofler
9:59 p.m.
Chris Murphy wrote:
What happens on Fedora now, because applications are merged with the
OS, there are application updates that end up making some unnecessary
reboots compulsory. But with atomic + flatpak installations, there is
much better separation of when reboots are necessary. OS updates don't
need to happen as often, and only one reboot is needed, there no
longer a long monolithic offline update process during which time the
system can't be used. Applications can be separately updated, you
don't have to reboot and I'm pretty sure you don't even have to quit
the application during the update. Just quit and relaunch whenever,
and now you're using the new version.
But you still refuse to acknowledge that the same is mostly true with RPM
updates in the real world unless one uses GNOME Software that forces offline
updates on everybody:
* If you update system packages, you reboot AFTER the update. It is not
actually necessary to reboot FOR the update as GNOME Software does.
* If you update leaf applications, you just have to restart the application
and not reboot at all. It depends on the application whether it actually
needs to be restarted (which is the only place where the container helps).
And IMHO, the monolithic all-or-nothing approach of ostree is a drawback,
not an advantage.
Kevin Kofler
10:10 p.m.
Dominik 'Rathann' Mierzejewski wrote:
The bundling thing is what I'm afraid of. If we don't make it
a
requirement or at least a strong recommendation to unbundle libraries
from Flatpaks, then we'll end up with Android app store-like
ecosystem, where everyone bundles everything which is not in one of the
runtimes and even runtimes duplicate libraries between each other,
because it's easy and not forbidden.
It's even required. There is no support for unbundling anything beyond the
runtime at all, nor can runtimes share files without duplicating them. This
is exactly why I consider Flatpak a no go.
Kevin Kofler
3:24 a.m.
On 20 July 2017 at 04:10, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
It's even required. There is no support for unbundling anything
beyond the
runtime at all, nor can runtimes share files without duplicating them.
Sure they can. If you install the KDE runtime and the GNOME runtime,
these are both built upon the Freedesktop runtime and share a huge
number of files. Any duplicate files get deduplicated on disk -- you
don't even download the duplicates when you update either or both of
them.
This is exactly why I consider Flatpak a no go.
Sure, and I don't think there's *anything* anyone can say to change
your mind on that even when they tell you you're wrong. You're
ignoring people when they correct you, and trying to make drama out of
things that are just not true. You've made it very clear on the
mailing list all the reasons why you think it's designed by idiots who
don't understand the One True RPM way, and I'm sure a good few people
on this list are just filtering your messages. If you come up with
well researched questions and reach out to us with a pleasant tone,
then we'll respond. Otherwise I'm just going to ignore all your posts
as well. Sorry to be blunt.
Richard.
6:44 a.m.
On Thursday, 20 July 2017 at 10:24, Richard Hughes wrote:
On 20 July 2017 at 04:10, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
> It's even required. There is no support for unbundling anything beyond the
> runtime at all, nor can runtimes share files without duplicating them.
Sure they can. If you install the KDE runtime and the GNOME runtime,
these are both built upon the Freedesktop runtime and share a huge
number of files. Any duplicate files get deduplicated on disk -- you
don't even download the duplicates when you update either or both of
them.
That's pretty cool (thanks, ostree), even if not ideal (binaries have
to be bit-identical). However, given that Fedora Flatpaks will be built
by koji using Fedora buildroots, this should work just fine.
Now, if only the runtime could be constructed "virtually"
(symlinks/hardlinks?) using the installed RPMs if the binaries match...
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:49 a.m.
/*Richard Hughes*/ wrote on Thu, 20 Jul 2017 09:24:10 +0100:
On 20 July 2017 at 04:10, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
> It's even required. There is no support for unbundling anything beyond the
> runtime at all, nor can runtimes share files without duplicating them.
Sure they can. If you install the KDE runtime and the GNOME runtime,
these are both built upon the Freedesktop runtime and share a huge
number of files. Any duplicate files get deduplicated on disk -- you
don't even download the duplicates when you update either or both of
them.
As Fedora is going to use (IIRC) Flatpack's in OCI format rather than
ostree, does it also work with OCI images? Both deduplication on disk,
and also delta-downloads?
7:53 a.m.
/*Colin Walters*/ wrote on Tue, 18 Jul 2017 15:43:12 -0400:
On Tue, Jul 18, 2017, at 02:58 PM, Chris Murphy wrote:
>> But if I've understood correctly, any changes to the base will be discarded
>> when you update the base image. right?
No; `rpm-ostree install` is persistent, and so are other changes like
`rpm-ostree initramfs --enable` and so is the recently added `ex override`:
https://github.com/projectatomic/rpm-ostree/pull/852
A bit more information about layering and live changes:
http://www.projectatomic.io/blog/2017/06/rpm-ostree-v2017.6-released/
Thanks. But, is it also true for package removals? e.g. If I remove
package foo, it won't appear again when the base image is updated,
correct? (If correct, will it be downloaded and discarded, or it won't
be downloaded in the first place?).
Regards,
Hedayat
8:17 a.m.
On Thu, 2017-07-20 at 17:19 +0430, Hedayat Vatankhah wrote:
/*Richard Hughes*/ wrote on Thu, 20 Jul 2017 09:24:10 +0100:
> On 20 July 2017 at 04:10, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> > It's even required. There is no support for unbundling anything beyond the
> > runtime at all, nor can runtimes share files without duplicating them.
>
> Sure they can. If you install the KDE runtime and the GNOME runtime,
> these are both built upon the Freedesktop runtime and share a huge
> number of files. Any duplicate files get deduplicated on disk -- you
> don't even download the duplicates when you update either or both of
> them.
As Fedora is going to use (IIRC) Flatpack's in OCI format rather than
ostree, does it also work with OCI images? Both deduplication on disk,
and also delta-downloads?
Good question!
Deduplication on disk works because Flatpak will unpack the downloaded
OCI image into the local OSTree repository.
Delta-downloads do not work, however. Every time a flatpak or runtime is
updated, the whole flatpak or runtime needs to be downloaded.
For this reason, it may be interesting to, once everything is built,
explode the OCI Images into a OSTree repository for download. (If we do
things right, we could even get delta-downloads for server containers as
well...)
The issue with this is that nobody has yet figured out how to handle
OSTree repositories within the Fedora mirror infrastructure. While
OSTree repositories can be mirrored efficiently, they can't be
mirrored efficiently by rsync.
But if we figure that one out.. in any case, this is a separate step
that can be done once we get the basics of building flatpaks working.
Owen
8:38 a.m.
On Thu, Jul 20, 2017, at 08:49 AM, Hedayat Vatankhah wrote:
As Fedora is going to use (IIRC) Flatpack's in OCI format rather
than
ostree, does it also work with OCI images? Both deduplication on disk,
and also delta-downloads?
dedup is a tricky topic since we use SELinux;
https://github.com/flatpak/flatpak/issues/927
As far as ostree vs OCI, that's indeed a downside; OCI doesn't have them
today. That said, I think there'll be some work in this space.
1:13 p.m.
On 7/19/2017 8:05 AM, Owen Taylor wrote:
On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann'
Mierzejewski
wrote:
> On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote:
> [...]
>> An example of where conditionals may be useful is when a library is
>> bundled into a Flatpak - the rebuild for the flatpak could skip
>> building the developer docs because they have complicated build
>> dependencies (graphviz or whatever.) We'll have to see how frequent
>> that is as we work through real examples.
> The bundling thing is what I'm afraid of. If we don't make it a
> requirement or at least a strong recommendation to unbundle libraries
> from Flatpaks, then we'll end up with Android app store-like
> ecosystem, where everyone bundles everything which is not in one of
> the
> runtimes and even runtimes duplicate libraries between each other,
> because it's easy and not forbidden. And since there's no easy way
> to track bundled stuff inside Flatpaks, we're much worse off than
> where we are with RPM packages currently.
Bundling enables some of the key features of Flatpak - the ability to
try out new versions of an application even if they require library
versions newer than what you have on your system, the ability to have a
single binary package that can be installed on different Linux
distributions, the assurance that installing an application will never
prevent you from upgrading your operating system due to missing
dependencies, and so forth.
And yes, there are downsides from bundling. But we're trying to address
those downsides as much as possible. Some of that is in the Flatpak
system:
* Runtimes mean that common libraries (libc, X11, etc) and libraries
that often have security updates (image libraries, crypto libraries)
will not be bundled.
* The use of ostree for storage means that if the exact same file is
bundled in two separate Flatpaks, it will be only stored on disk and in
memory once.
And some of that is going to be in how we generate Flatpaks from Fedora
content:
* Bundled libraries will not be arbitrary source code builds, they will
be built from the exact same spec files in dist-git.
* We will track (via the PDC) what versions of what packages are
included in every Flatpak runtime and app we ship, and can
automatically rebuild and update the runtime and apps as needed.
* We will include a manifest of the component RPM versions in each
Flatpak runtime and app.
There are definitely some open questions, and we'll have to pay close
attention to how much duplication we are getting in practice, and look
at whether we need to adjust the composition of the Fedora runtime and
our build methods to reduce duplication, but it's definitely not going
to be a Wild West where every application you install on your system
has its own copy of libz that was downloaded somewhere off the
internet.
Isn't one of the selling points for this, however, the use of
Flatpacks
written/produced by generic third party app vendors to publish without
specially constructed packages by Fedora participants? If that's the
case, what's to say that any upstream Flatpack/container/image will have
the same care of using runtime definitions or expectations as the ones
curated by the Workstation WG (or Freedesktop group, or whomever)? Why
couldn't a third-party app creator bundle libz on a regular basis
"because it's easier"?
Of course, one could do that in an RPM too, but then it would be berated
as a "badly constructed RPM". It seems like one of the point of
Flatpacks is to reach out to app developers who can't be bothered to
write a decent .spec file but whose apps we still want to have easily
installable by Fedora users.
Multiple versions of apps installed in parallel aside, how does this not
end us back up in the same place?
-jc
1:41 p.m.
On Thu, 2017-07-20 at 11:13 -0700, Japheth Cleaver wrote:
On 7/19/2017 8:05 AM, Owen Taylor wrote:
> On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann' Mierzejewski
> wrote:
> > [...]
> Bundling enables some of the key features of Flatpak - the ability to
> try out new versions of an application even if they require library
> versions newer than what you have on your system, the ability to have a
> single binary package that can be installed on different Linux
> distributions, the assurance that installing an application will never
> prevent you from upgrading your operating system due to missing
> dependencies, and so forth.
>
> And yes, there are downsides from bundling. But we're trying to address
> those downsides as much as possible. Some of that is in the Flatpak
> system:
> [...]
> And some of that is going to be in how we generate Flatpaks from Fedora
> content:
> [...]
>
Isn't one of the selling points for this, however, the use of Flatpacks
written/produced by generic third party app vendors to publish without
specially constructed packages by Fedora participants? If that's the
case, what's to say that any upstream Flatpack/container/image will have
the same care of using runtime definitions or expectations as the ones
curated by the Workstation WG (or Freedesktop group, or whomever)? Why
couldn't a third-party app creator bundle libz on a regular basis
"because it's easier"?
The main point I'll make here is that the thread is discussing my change
proposal to generate flatpaks out of Fedora content, and so the main
question is whether those flatpaks are going to handle bundled dependencies
in a sane way. Not about all possible flatpaks.
(Note that the ability to install third party flatpaks is not listed as
a benefit of my change proposal... and we already have that in F25/F26
in any case.)
Of course, one could do that in an RPM too, but then it would be
berated
as a "badly constructed RPM". It seems like one of the point of
Flatpacks is to reach out to app developers who can't be bothered to
write a decent .spec file but whose apps we still want to have easily
installable by Fedora users.
While there are strong barriers in place to make sure that the RPMs that
are *part* of Fedora are high quality, we don't have any barriers in place
to make sure that an RPM a user installs from a third party is high quality -
if a users install the Google Chrome, or Adobe Flash, or Skype, or whatever RPM
it probably doesn't meet your requirements for a high-quality RPM.
It's not really any different with Flatpaks, other than that we have some
extra protections that aren't there with RPMs:
- A flatpak can't make arbitrary modifications to your system at
install time.
- libraries installed in a flatpak cannot affect any other application
- flatpaks are potentially sandboxed at runtime
- The source repository when you install a flatpak only is used to
update that flatpak and does not participate in general package
resolution.
So the potential damage from a bad flatpak is more limited.
Owen
7:12 p.m.
Richard Hughes wrote:
Sure they can. If you install the KDE runtime and the GNOME runtime,
these are both built upon the Freedesktop runtime and share a huge
number of files. Any duplicate files get deduplicated on disk -- you
don't even download the duplicates when you update either or both of
them.
The files are still technically duplicated, they just happen to be
deduplicatable (and as pointed out by Hedayat Vatankhah elsewhere in this
subthread, the duplicates will still have to be downloaded in the
implementation that is being proposed at this time, which offers the
runtimes as single-file OCI blobs). Sharing without duplicating would mean
having dependencies between the runtimes, so that the KDE runtime can
actually Require the Freedesktop runtime. But at that point, wouldn't we
just be reinventing RPM?
You've made it very clear on the mailing list all the reasons why
you
think it's designed by idiots who don't understand the One True RPM way,
I did NOT use the 'i' word, please stop putting words in my mouth!
Kevin Kofler
5:56 p.m.
>>>> "OT" == Owen Taylor
<otaylor(a)redhat.com> writes:
OT> The issue with this is that nobody has yet figured out how to handle
OT> OSTree repositories within the Fedora mirror infrastructure. While
OT> OSTree repositories can be mirrored efficiently, they can't be
OT> mirrored efficiently by rsync.
Is the problem simply quantity of files? Because I have been doing work
related to that in the form of https://pagure.io/quick-fedora-mirror and
it's worked pretty well so far.
If the problem is simply the volume of churn or something else, then
that's a separate problem which may or may not be alleviated by
quick-fedora-mirror. But I recall that ostree stuff was moved out of
the main repository mostly due to the huge file count.
- J<
6:40 p.m.
On Jul 20, 2017, at 5:12 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
Richard Hughes wrote:
> Sure they can. If you install the KDE runtime and the GNOME runtime,
> these are both built upon the Freedesktop runtime and share a huge
> number of files. Any duplicate files get deduplicated on disk -- you
> don't even download the duplicates when you update either or both of
> them.
The files are still technically duplicated, they just happen to be
deduplicatable (and as pointed out by Hedayat Vatankhah elsewhere in this
subthread, the duplicates will still have to be downloaded in the
implementation that is being proposed at this time, which offers the
runtimes as single-file OCI blobs). Sharing without duplicating would mean
having dependencies between the runtimes, so that the KDE runtime can
actually Require the Freedesktop runtime.
Couldn't the files all be addressed by hash or even use a tool like casync?
10:41 p.m.
On Wed, Jul 19, 2017 at 5:17 AM, Jiří Eischmann <eischmann(a)redhat.com> wrote:
Nico Kadel-Garcia píše v Út 18. 07. 2017 v 22:44 -0400:
> On Fri, Jul 14, 2017 at 12:59 PM, Debarshi Ray <rishi.is(a)lostca.se>
> wrote:
> > On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> > > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > > F29: packagers (of graphical applications) must create
> > > > Flatpaks of
> > > > their applications if possible. They *may* keep standard
> > > > RPM
> > > > packaging.
> > >
> > > At least we see where this is going.
> > >
> > > If RPMs of the graphical application work fine now, what on earth
> > > is
> > > the point of forcing packagers to make Flatpaks? Sandboxing
> > > isn't one
> > > of them - as already explained, sandboxing is orthogonal to
> > > packaging.
> >
> > Huh? How would you get sandboxing without Flatpaks? Unless you are
> > proposing a different sandboxing technology.
>
> By putting them in "/opt", the way other sanely packaged 3rd party
> components do?
How does that ensure any sandboxing?
Complete sandboxing, with isolation from the network stack and the
rest of the host's filesystem? It doesn't. But functional sandboxing,
where a full software suite with its own libraries and binaries to be
supported separately from the rest of the operating sytem, Yeah, it
works pretty well to set up a separate workspace there and wrap the
calls of that customized suite in an "enable" script or a shell
wrapper, much as the Software Collections for RHEL have been doing
functionally for years for software backported from Fedora testing.
Even a chroot cage can be run there for service isolation from the
rest of the system. Gnome packaging... well, that's considerably
harder because it spews into $HOME/.gnome, in manners inconsistent
between even minor releases. Packaging Gnome looks like a fabulous
idea at first glance. It's one of those situations where the "first
90% takes 90% of the work, and the last 10% takes the next 300% of the
work".
10:44 a.m.
As I understand it, the problem is that mirrors want to mirror Fedora using generic rsync,
and ostree repositories have huge numbers of small files. To use rsync requires, at a
minimum, a full directory walk, calling stat() every file on both the source and
destination.
From the little I know about casync, I expect it to be better handling lots of small
files, but I don't think it can avoid the full directory walk.
If we can get mirrors to run custom software, then a really good protocol for mirroring
OSTree repositories is OSTree - especially if the source repository is hosted with HTTP/2
support. Because of the content-addressed-storage nature of OSTree, no matter how large
some portion of the repository is, if it hasn't changed, it takes no time to transfer
it.
I'd have to study your code to really know how it would compare - it looks like what
it basically saves is that the source repository doesn't have to do the stat walk for
*every* client, just once, but the clients still do a full walk each time. If it's
more palatable to mirrors to run something that is just standard software + a zsh script,
then it could be a big improvement, but I wouldn't expect it to be nearly efficient as
mirroring via OSTree.
The proof would be in the pudding - in testing how these different mechanisms actually
compare in practice.
Owen
----- Original Message -----
> >>>>> "OT" == Owen Taylor <otaylor(a)redhat.com>
writes:
>
> OT> The issue with this is that nobody has yet figured out how to handle
> OT> OSTree repositories within the Fedora mirror infrastructure. While
> OT> OSTree repositories can be mirrored efficiently, they can't be
> OT> mirrored efficiently by rsync.
>
> Is the problem simply quantity of files? Because I have been doing work
> related to that in the form of https://pagure.io/quick-fedora-mirror and
> it's worked pretty well so far.
>
> If the problem is simply the volume of churn or something else, then
> that's a separate problem which may or may not be alleviated by
> quick-fedora-mirror. But I recall that ostree stuff was moved out of
> the main repository mostly due to the huge file count.
>
> - J<
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
2468
days inactive
2484
days old
197 comments
51 participants
participants (51)
-
Alexander Bokovoy -
Andreas Tunek -
Andrew Lutomirski -
Bastien Nocera -
Ben Rosser -
Bill Nottingham -
Chris Murphy -
Christian Dersch -
Christian Schaller -
Colin Walters -
Daniel P. Berrange -
Daniel Walsh -
Debarshi Ray -
Dennis Jacobfeuerborn -
Dominik 'Rathann' Mierzejewski -
Dusty Mabe -
Emmanuel Seyman -
Florian Weimer -
Hedayat Vatankhah -
Japheth Cleaver -
Jaroslav Reznik -
Jason L Tibbitts III -
Jiří Eischmann -
Joonas Sarajärvi -
Kamil Dudka -
Kevin Kofler -
Lars Seipel -
Martin Kolman -
Mathieu Bridon -
Matthew Miller -
mcatanzaro＠gnome.org -
Michael Catanzaro -
Michael Stahl -
Neal Gompa -
Nico Kadel-Garcia -
nicolas.mailhot＠laposte.net -
Owen Taylor -
Petr Pisar -
Pierre-Yves Chibon -
Przemek Klosowski -
Rahul Sundaram -
Randy Barlow -
Richard Hughes -
Richard W.M. Jones -
Samuel Sieb -
stan -
Stephen John Smoogen -
Tom Hughes -
Vít Ondruch -
William Moreno -
Zbigniew Jędrzejewski-Szmek