Fedora packages versus upstream Flatpaks

Posted Feb 8, 2023 10:07 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Fedora packages versus upstream Flatpaks by Conan_Kudo
Parent article: Fedora packages versus upstream Flatpaks

The question becomes whether or not the contribution is valuable, or just duplication of effort. A distro packager who expects to only be responsible for the builds in their distro of choice, and nothing more, is just duplicating effort; there's no added value from having something built as a Fedora RPM as well as a Debian dpkg and a CentOS RPM.

A distro packager who does things like testing against newer library versions and reporting back to upstream that it's possible to move from libfoo-1.1.1 to libfoo-1.8.6 safely is valuable. As is a distro packager who handles front line support, from recommending tutorials to people who've installed the program and now want to be told how to use it, all the way through to producing good bug reports from user reports of the form "I installed it and it doesn't work".

Fedora packages versus upstream Flatpaks

Posted Feb 15, 2023 15:03 UTC (Wed) by immibis (subscriber, #105511) [Link] (2 responses)

I'm not familiar with the underlying differences between Debian and Fedora, but I'm sure there are some (think sysvinit vs systemd, X vs Wayland, /bin vs /usr/bin). Distributions are opinionated; packages built for different distributions have different opinions.

Maybe one day effort will be merged into a distribution-development-kit based on bitbake or portage. Then Fedora can be DDK with one set of custom packages (e.g. branding) and compile options, and Ubuntu can be a different one.

The package manager itself is a relatively small amount of work compared to the work required to actually make the packages.

Fedora packages versus upstream Flatpaks

Posted Feb 15, 2023 17:24 UTC (Wed) by Wol (subscriber, #4433) [Link]

Hmmm ...

> Maybe one day effort will be merged into a distribution-development-kit based on bitbake or portage. Then Fedora can be DDK with one set of custom packages (e.g. branding) and compile options, and Ubuntu can be a different one.

Well, portage is a damn good system for building a distro. Throw in systemd as the one init system to rule them all :-)

But I think where systemd and portage both (like a huge amount of Open Source software) fall down badly is the lack of decent STARTER documentation. Open Source documentation is good, but it's mostly of the sort that only makes sense once you already know what it means - it's a reference not a tutorial. I've written my own systemd init file and it was torture, because I didn't know where to start. And I still think it's got a number of nasty glitches that I need to debug. However I really don't think SystemV would have been any easier ...

Cheers,
Wol

Fedora packages versus upstream Flatpaks

Posted Feb 20, 2023 12:58 UTC (Mon) by farnz (subscriber, #17727) [Link]

But those opinions are of very little value if the packager isn't communicating the results of complying with those opinions upstream. If a distro packager is building for X11 only, and upstream removes all X11 support (making their package Wayland-only), then the distro's opinion stops having any weight, since it becomes "remove package" versus "stop holding the opinion that X11 is required".

To be of value beyond simply providing a nice way to do ./configure && make install, packagers need to be communicating with upstream, and ensuring that the reasons behind distro opinions are respected upstream (which is hard work in its own right - the packager job is not simple or easy). If they're not, then distro packagers are going to duplicate each other's work, and upstream is not even going to realise that distro packagers have opinions that differ from theirs, nor why.

This becomes problematic if upstream's decision making results in them dropping code distributions need to implement their opinions - if you remove X11 support code because you think that everyone's using Wayland now, but my distribution package patches out Wayland support and only builds the X11 version, then we get an unpleasant collision. Had I been telling you why my package patches out Wayland support, you'd almost certainly have kept X11 support, or worked with me to fix the reasons why I patched out Wayland.