4 ms·

There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs

There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other user can use it, develop for it, and send fixes upstream.

creshal 4y ago
The strawman sounds compelling on the surface, but that's not what happens in practice: Bug fixes are sent upstream by all relevant distributions, and they regularly cooperate with each other directly, as well as upstream. The "new world" of users of all distributions working together has been reality for the past 20+ years.
noirscape 4y ago
> Bugs should be fixed upstream, not kept in distro specific silos. This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old. With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}). The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. [0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.
- creshal 4y ago
  And even Debian tries to upstream fixes where feasible, which isn't too uncommon for security vulnerabilities, they tend to lurk in old parts of codebases that haven't been refactored for a while.
- ParetoOptimal 4y ago
  > The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. I'm pretty sure this isn't true. What does upstream emacs have to do for Nix to provide https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/editors/emacs/generic.nix https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/appli... I will agree though that applications which have their own update mechanism or do other things that make reproducibility harder are much more difficult to create a Nix expression for.
account42 4y ago
Bugs should be fixed upstream but unfortunately sometimes upstream does not see them as bugs - for example, telemetry.

creshal 4y ago

The strawman sounds compelling on the surface, but that's not what happens in practice: Bug fixes are sent upstream by all relevant distributions, and they regularly cooperate with each other directly, as well as upstream. The "new world" of users of all distributions working together has been reality for the past 20+ years.

noirscape 4y ago

> Bugs should be fixed upstream, not kept in distro specific silos. This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old. With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}). The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. [0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.

creshal 4y ago
And even Debian tries to upstream fixes where feasible, which isn't too uncommon for security vulnerabilities, they tend to lurk in old parts of codebases that haven't been refactored for a while.
ParetoOptimal 4y ago
> The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. I'm pretty sure this isn't true. What does upstream emacs have to do for Nix to provide https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/editors/emacs/generic.nix https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/appli... I will agree though that applications which have their own update mechanism or do other things that make reproducibility harder are much more difficult to create a Nix expression for.

account42 4y ago

Bugs should be fixed upstream but unfortunately sometimes upstream does not see them as bugs - for example, telemetry.