Re: Fedora development of Snap packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jun 16, 2016 at 12:56 AM, Gerald Henriksen <ghenriks@xxxxxxxxx> wrote:
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
traditional way.

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 [1] 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 RPMs.

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 [2]", and I suspect that, too, would be a pretty controversial thing to do.

Ben Rosser

[1] 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.

[2] 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 exactly that.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux