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
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
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
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.