On Thu, Jun 16, 2016 at 12:56 AM, Gerald Henriksen <ghenriks(a)gmail.com>
On Wed, 15 Jun 2016 22:18:00 -0400, you wrote:
>Snaps function very much like how Apple's ecosystem does for software
>delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
>clear that the purpose of Snaps are to provide avenues to "encourage"
>people to lock into the Ubuntu platform.
>So far, I've seen people gloss over the real crux of the problem,
>which is that somehow we're trying to create walled gardens, and no
>one wants to fix that.
No, the problem is that the developers of open source projects and
languages have viewed the strict rules around packages in a
distribution as a problem, and have worked around it.
Swift (you know, the hot new language that still isn't in Fedora), Go,
Python, Node.js, etc. have all created their own "packaging" systems
to either bypass the traditional Linux distribution or to handle
running on macOS or Windows that don't have a packaging system.
Combine this with the fact that a lot of the development (most?) is no
longer happening on Linux for various reasons, and that the dependency
chain on a lot of software is a packaging nightmare, and you have
Ubuntu (with Snap), GNOME (with Flatpak), and the server people (with
Docker) all coming up with simpler ways to try and get stuff packaged
given the lack of volunteers to even try and get stuff packaged in the
The current method of packaging rpms in Fedora is not working - there
are simply too many things that aren't getting packaged - and a
simpler alternative needs to be found.
I do not entirely disagree with you (though others in this thread might).
It's important that we understand that if users want to install software
not packaged in Fedora, they will, using whatever method they can. Whether
that's installing RPMs from some other distro, installing whatever format
is provided by upstream, building it themselves, installing packages from
e.g. PyPI for Python modules, etc. For better or worse, a user is very
rarely going to sit down and learn how to package the thing they're trying
to install for Fedora and try to get it included in our repositories.
So for example, if I need to install a Python package that's not available
through our repositories, I'll install it using pip. (Sometimes, because
I'm a packager, I say to myself "hm, I should package this for Fedora", but
not always). There's nothing wrong with that. *However*, if given the
option, I would always prefer to install the package from our repositories.
So I think that flatpaks  are a good thing in that they extend the
amount of software users can (hopefully easily) install on their systems,
because, as you say, there are things that aren't getting packaged due to
various reasons. I completely agree! Making it easier for users to install
software not packaged in Fedora isn't a bad thing-- otherwise, why do we
ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
in on this thread initially, is with the idea that these new containerized
packaging systems are in some way *superior* to traditional packaging. Or
at least that's what I read between the lines of the proposal to allow
upstreams to ask for their flatpaks or whatever to be shipped in place of
I strongly disagree with this. There is still a lot to be said, I think,
for having as much of the software on your system as possible built and
linked against system-wide libraries.
In my vision of the future, we'd ship flatpaks and friends as a supplement
to, but not as a replacement of, RPMs. In fact, we'd go the other way. If
some GUI application was install-able as a flatpak in Fedora, and there was
someone interested in maintaining a downstream package, we would allow and
encourage them to do so. Now, this is all "maintainer interest
permitting"-- if an upstream flatpak is available and nobody wants to
maintain the downstream package, then that's fine too. The package can be
orphaned and retired and users will still be able to install the software
through the flatpak (which is, obviously, superior to users not being able
to install the software at all!).
But if someone is willing to maintain a traditional package of a piece of
software that also has a flatpak available, I really think we should let
them do so. We're not, as so far as I know, in the habit of telling the
maintainers of leaf Python packages "please retire your package and let
users install it using pip ", and I suspect that, too, would be a pretty
controversial thing to do.
 flatpaks, snaps, etc., or similar technology. When I refer to
"flatpaks", I'm really talking about this type of upstream-provided
container package in general, not the specific GNOME implementation.
 Sure, the current difference here is that dnf, etc. can't install
Python packages direct from PyPI, at least at the moment, so this is a
slightly contrived example. But, assuming one doesn't exist already, I
don't believe it would be terribly difficult to write a dnf plugin to do