On 15 Jun 2016 02:19, "Michael Catanzaro" <mcatanzaro(a)gnome.org> wrote:
Hi,
You're right, we hadn't yet planned for how to handle spins (at least
I'm unaware of any such plans). Don't worry, nobody's going to start
removing packages if that means making apps inaccessible to folks not
using Workstation. Some compatibility story is clearly needed
beforehand. Igor suggested that dnf could transparently switch to
installing a Flatpak, for instance.
Also, keep in mind that Flatpaks are not the only new type of software
we intend to support in Fedora. I know other folks are looking into
supporting Docker containers; I believe that's a Server WG initiative?
This is why all our packages just moved under the rpms namespace in
Fedora git.
On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:
> I suspect this view originates in a very Gnomeish view of the world
> where upstream and the Fedora packagers are very close but I wonder
> how
> well it matches with situations where upstream and distros have a
> more
> antagonistic relationship...
It's designed for third party application developers; packages work
great for big coherent projects like GNOME and KDE that all distros
package, but they're terrible for an upstream developer trying to
distribute one piece of software to users on 20 different distros. By
making [specific, approved] upstream Flatpaks accessible in GNOME
Software, no longer does upstream have to deal with Fedora packagers
saying "you can't bundle this and that" or "your package doesn't
build
with GCC 74" or "this violates or packaging guidelines," nor worry
about downstream patches causing different behavior in different
distros. Instead, Fedora just gets out of the way. The thinking is that
this will make upstreams like us more... especially since it allows
them to control the pace of updates.
Some upstreams are rather poor at tracking their third party libraries and
providing timely security updates.
One of the things our process ensures with the very strong preference to
unbundling is that our users get, for example, openssl fixes regardless of
how long an upstream takes.
On the flip side this will make things easier for companies like GOG to
package, support and distribute software purchased.
If we allow this to bypass our packaging guidelines why even have them for
our existing packagers?
Please don't forget about automated builds via kickstart and CM
technologies like ansible in the desire to push this out.
This sounds like it ultimately could be a lengthy conversation, similar to
the SCL one that stalled.
You might want to start on the FPC ticket and discussions sooner rather
than later if you want to target either F25 or F26 (ie any supported
release in the next 12 months).