5 ms·

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what t

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong. If dependency version management is too hard, someone is doing something wrong - not sure who, could be a library maintainer or an app maintainter. Let's not ship half an OS with every app to avoid this stuff.

mikae1 4y ago
> That's kinda what the distros ARE. What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.
- mulmen 4y ago
  But if hundreds of distro maintainers don’t do it then millions of users have to do it.
  - tapoxi 4y ago
    No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.
    - prmoustache 4y ago
      History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care
      - doublepg23 4y ago
        Why would you use software if you think the dev is too incompetent to package it?
        tremon 4y ago
        Because I trust that distro maintainers catch the most obvious errors before packaging and releasing the software.
        ninkendo 4y ago
        Package it for what? There are a lot of distros. Should the dev be packaging it for every one of them? Debian, red hat, suse, arch, other more esoteric ones? Which distro versions? How many years back should they be maintaining the packages?
        doublepg23 4y ago
        …the context was Flatpaks and snaps which directly address it by simplifying the process… the developer would explicitly avoid that confusion.
      - curt15 4y ago
        How often do distribution maintainers actually audit the package source code?
        prmoustache 4y ago
        I wasn't talking about audit but dependency lifecycle.
      - ranger207 4y ago
        History has shown that distro maintainers aren't perfect at patching security vulnerabilities either and that sandboxing is useful regardless. It also shows that user want working software and will go through the effort of inventing new package formats like flatpak to work around distro maintainers. Maintainers now have a choice between complaining that everyone else is doing it wrong and eventually becoming irrelevant, or getting with the program and maybe even offering their expertise to accomplish what people want to do
    - moreresearchplz 4y ago
      Why should a developer of a free and open-source application, provided free of charge and without any guarantees, have any obligations to package and even test their software on random, thirdparty distributions? If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unpaid developer who created it.
      - esarbe 4y ago
        That's the point of flatpaks - you don't. You build one flatpak and it will work for all distributions.
    - dizhn 4y ago
      You can't have distro specific policies using this methodology.
    - mulmen 4y ago
      It’s called a distribution. Literally distributing the software. The distro deals with integrating all the packages into a single compatible system. This includes setting options to maintain system compatibility. Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These are not distribution specific. The separation of concerns is very clear. If a distribution doesn’t package the code then the user is left to build the application themselves. It’s impractical that a developer would build and maintain their own packages for every flavor of every distribution.
      - zorr 4y ago
        The discussion is mostly about what a distribution should contain. I don't think a distribution has to contain all the possible software applications in existence. Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy. But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications. However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately. This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.
        mulmen 4y ago
        That’s a reasonable position but it puts developer and maintainer experience ahead of user experience. Flatpak and friends are a pain in the ass to use and offer a shitty UX. Having a single point of contact and well understood mechanism for software management is a feature for users. I don’t expect my distribution to have every software package ever. I do expect it to fulfill my needs. As long as there are applications in the repository that do what I need I am happy.
    - matheusmoreira 4y ago
      No. I trust distribution maintainers a lot more than I trust other developers.
KyeRussell 4y ago
Ah, a bunch of “you’re holding it wrong”s, completely devoid from reality. This certainly is an argument about Linux.
vinyl7 4y ago
Arch Linux would like to have a word
- lapinot 4y ago
  This. Also void and alpine. Which have simple, no-nonsense package formats. We get it that deb and rpm are a hassle to learn and write, but it's completely a false dichotomy to say snap or flatpak are the only alternative. In fact they push a widely different model of software distribution, one that completely destroys "user unions" which is a crucial aspect of what distributions are.
  - vetinari 4y ago
    > We get it that deb and rpm are a hassle to learn and write, They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. > false dichotomy to say snap or flatpak are the only alternative we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing. Edit: names
    - mestelan 4y ago
      silverblue ;-)
      - vetinari 4y ago
        you are right, brainfart ;)
    - wootland 4y ago
      > They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. > we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing. The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!
veeti 4y ago
Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.
- Nursie 4y ago
  > You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
  - biorach 4y ago
    Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.
    - phkahler 4y ago
      So upgrade the whole thing. It's open source so in most cases that's possible.
      - PlutoIsAPlanet 4y ago
        You're shifting more work onto distros and users that shouldn't be work in the first place, and basically preventing non-linux literate people from using their OS. If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.
        Nursie 4y ago
        Maybe you should, those dependencies may contain vulnerabilities.
zorr 4y ago
> That's kinda what the distros ARE For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository. Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users. Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase. This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed. Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)
- JohnFen 4y ago
  > If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository. Yes, and that's a good thing for a whole bunch of reasons. If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual. > Essentially, something like Flatpak is a middle-ground solution Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way. I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.
panick21_ 4y ago
> That's kinda what the distros ARE. Yeah but that the worst part of what they ARE and if they didn't have to spend so much time doing that maybe they could do more innovative things.

mikae1 4y ago

> That's kinda what the distros ARE. What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.

mulmen 4y ago
But if hundreds of distro maintainers don’t do it then millions of users have to do it.
- tapoxi 4y ago
  No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.
  - prmoustache 4y ago
    History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care
    - doublepg23 4y ago
      Why would you use software if you think the dev is too incompetent to package it?
      - tremon 4y ago
        Because I trust that distro maintainers catch the most obvious errors before packaging and releasing the software.
      - ninkendo 4y ago
        Package it for what? There are a lot of distros. Should the dev be packaging it for every one of them? Debian, red hat, suse, arch, other more esoteric ones? Which distro versions? How many years back should they be maintaining the packages?
        doublepg23 4y ago
        …the context was Flatpaks and snaps which directly address it by simplifying the process… the developer would explicitly avoid that confusion.
    - curt15 4y ago
      How often do distribution maintainers actually audit the package source code?
      - prmoustache 4y ago
        I wasn't talking about audit but dependency lifecycle.
    - ranger207 4y ago
      History has shown that distro maintainers aren't perfect at patching security vulnerabilities either and that sandboxing is useful regardless. It also shows that user want working software and will go through the effort of inventing new package formats like flatpak to work around distro maintainers. Maintainers now have a choice between complaining that everyone else is doing it wrong and eventually becoming irrelevant, or getting with the program and maybe even offering their expertise to accomplish what people want to do
  - moreresearchplz 4y ago
    Why should a developer of a free and open-source application, provided free of charge and without any guarantees, have any obligations to package and even test their software on random, thirdparty distributions? If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unpaid developer who created it.
    - esarbe 4y ago
      That's the point of flatpaks - you don't. You build one flatpak and it will work for all distributions.
  - dizhn 4y ago
    You can't have distro specific policies using this methodology.
  - mulmen 4y ago
    It’s called a distribution. Literally distributing the software. The distro deals with integrating all the packages into a single compatible system. This includes setting options to maintain system compatibility. Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These are not distribution specific. The separation of concerns is very clear. If a distribution doesn’t package the code then the user is left to build the application themselves. It’s impractical that a developer would build and maintain their own packages for every flavor of every distribution.
    - zorr 4y ago
      The discussion is mostly about what a distribution should contain. I don't think a distribution has to contain all the possible software applications in existence. Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy. But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications. However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately. This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.
      - mulmen 4y ago
        That’s a reasonable position but it puts developer and maintainer experience ahead of user experience. Flatpak and friends are a pain in the ass to use and offer a shitty UX. Having a single point of contact and well understood mechanism for software management is a feature for users. I don’t expect my distribution to have every software package ever. I do expect it to fulfill my needs. As long as there are applications in the repository that do what I need I am happy.
  - matheusmoreira 4y ago
    No. I trust distribution maintainers a lot more than I trust other developers.

KyeRussell 4y ago

Ah, a bunch of “you’re holding it wrong”s, completely devoid from reality. This certainly is an argument about Linux.

vinyl7 4y ago

Arch Linux would like to have a word

lapinot 4y ago
This. Also void and alpine. Which have simple, no-nonsense package formats. We get it that deb and rpm are a hassle to learn and write, but it's completely a false dichotomy to say snap or flatpak are the only alternative. In fact they push a widely different model of software distribution, one that completely destroys "user unions" which is a crucial aspect of what distributions are.
- vetinari 4y ago
  > We get it that deb and rpm are a hassle to learn and write, They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. > false dichotomy to say snap or flatpak are the only alternative we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing. Edit: names
  - mestelan 4y ago
    silverblue ;-)
    - vetinari 4y ago
      you are right, brainfart ;)
  - wootland 4y ago
    > They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. > we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing. The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

veeti 4y ago

Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

Nursie 4y ago
> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
- biorach 4y ago
  Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.
  - phkahler 4y ago
    So upgrade the whole thing. It's open source so in most cases that's possible.
    - PlutoIsAPlanet 4y ago
      You're shifting more work onto distros and users that shouldn't be work in the first place, and basically preventing non-linux literate people from using their OS. If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.
      - Nursie 4y ago
        Maybe you should, those dependencies may contain vulnerabilities.

zorr 4y ago

> That's kinda what the distros ARE For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository. Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users. Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase. This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed. Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)

JohnFen 4y ago
> If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository. Yes, and that's a good thing for a whole bunch of reasons. If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual. > Essentially, something like Flatpak is a middle-ground solution Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way. I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.

panick21_ 4y ago

> That's kinda what the distros ARE. Yeah but that the worst part of what they ARE and if they didn't have to spend so much time doing that maybe they could do more innovative things.