13 ms·

What you are really saying is you want all software developers to publish Debian packages (no such thing as "apt" packages) compatible with your particular Debi

What you are really saying is you want all software developers to publish Debian packages (no such thing as "apt" packages) compatible with your particular Debian distribution, even though they might be using a different Debian based distribution, a completely different altogether, maybe even a different architecture, even though that compatibility isn't their primary concern.

creshal 4y ago
The whole point of a distribution is that this job is done by the distributors, not the authors.
- alkonaut 4y ago
  Is there a distribution (or whatever one would call it - a Linux) where the aim is to not be managing the whole end-user system of OS+Apps, but just the OS. E.g. similar to Windows, or Android?
  - drbig 4y ago
    There are operating systems - like FreeBSD - which have a very strong and clear distinction between the Operating System base and third-party software.
  - dikei 4y ago
    For server there's Flatcar Container Linux, which only provide just enough to run containers. Everything else is provided by the container packager.
  - qbasic_forever 4y ago
    Arch Linux is pretty faithful to shipping software exactly or as close as possible to as the upstream authors intended. It's on a rolling release which means you kind of get a firehose of nonstop major version updates though, whether you want them or not.
    - geokon 4y ago
      how does that work in practice？ upstream didn't build with all the dependencies at the same version as the latest in the arch repo. Nor are most upstream developers bumping all their dependency versions constantly if you're a big player like ubuntu/debian you can go to the authors/upstream and ask them to fix the program to work with their dependency versions (in say.. an LTS release). most would be glad to bc it's just something upstream needs to do once every couple years and doesn't need maintenance. If even thats too much and yyou want esomething even more handsoff/timeless then you make an Appimage. It'll work for ever With Arch youd need to constantly monitor the thing doesn't break？Are they just #yolo'ing dependency versions most of the time ？ (itd prolly work 99% of the time..)
      - creshal 4y ago
        In practice it works because GP is exaggerating. Arch does hold back library and/or program updates until they work together, or simply ships multiple major releases of libraries, and have a separate testing branch. Right now e.g. there's openssl (still at version 3.0.x, because nobody supports 3.1.x yet) and openssl-1.1 (1.1.x-y) to handle the rather slow migration of upstreams to the new major release.
  - viraptor 4y ago
    Fedora Silverblue https://silverblue.fedoraproject.org/ https://silverblue.fedoraproject.org/ You're expected to run most apps as flatpaks.
    - curt15 4y ago
      I stopped distro-hopping a few years ago after landing on Silverblue a few years ago (back when it was still called Fedora Atomic Workstation). While it doesn't satisfy all use cases, I view it as a boring (in a good way) 80-percent solution that normally just works.
    - pch00 4y ago
      Silverblue doesn't get a lot of press but it makes a really solid desktop OS.
      - PlutoIsAPlanet 4y ago
        Fedora has always been quite bad at branding and making their distro appealing. It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc. Stark contrast to something like https://vanillaos.org/ https://vanillaos.org/
  - creshal 4y ago
    No distribution forces you to use package managers for everything. Even before flatpak/snap, distributing (especially commercial) software as just archives or executable installers was/is perfectly possible. The caveat is, there's no common baseline for libraries. Graphics libraries, the libc itself, GUI widget libraries etc. will appear in different version combinations in different distributions, since they have different release schedules. So if you want to go the Windows/MacOS route and ship a readily compiled program for Linux, you have to vendor in a loooot more libraries, and they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.) Flatpaks/snaps try to solve this (poorly) by vendoring the entire kitchen sink and then some, which just creates more bloat and a worse DLL hell than Windows could ever have dreamed of. So using it for everything isn't really feasible still.
    - account42 4y ago
      > they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.) Simply don't vendor glibc and graphics drivers and you will be fine. Vendoring drivers doesn't make sense anyway as your application will be obsolete by the next HW cycle.
      - creshal 4y ago
        glibc breaks regularly, as does mesa occasionally, so it would realistically be required if you wanted win32-style 20+ years of backwards compatibility. And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly. And that sort of software doesn't really obsolete. Steam and GoG allow games to have a 10+ years long tail of slow but steady sales that don't really justify constant maintenance releases but still both let people enjoy good games (those don't really obsolete), and serve as advertisement for the developers' newer games.
        4y ago
  - JohnFen 4y ago
    Slackware, perhaps? Honestly, if you just want the naked OS, you don't need a distro at all. Or just don't use the package manager.
    - alkonaut 4y ago
      I'm curious what a Linux would look like that behaved more like windows or android in the sense that there isn't such a blurry line between the OS and its applications. For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? This is basically the Unix "I'm not just an OS, I'm a platform for building and running C programs" heritage that isn't properly hidden I think.
      - creshal 4y ago
        We've reached the point where the C ecosystem has so given up on having a package manager that isn't Linux distributions that Microsoft added WSL and Docker(-compatible) Linux images are the most widespread distribution format. I don't think we can still figure out a way to decouple the two again, and without that, we can't really create a Linux environment that isn't a package manager with an email client. And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.
      - JohnFen 4y ago
        > in the sense that there isn't such a blurry line between the OS and its applications. Interesting. It never occurred to me that there's a blurry line between the two. It seems to me that there's a very hard line between the two. I'm not sure I understand what you're saying here. > For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? I'm confused by this question, so forgive me if this answer isn't really addressing it. A package manager is a convenience, nothing more. Using one means makes your life easier in a number of ways. But not using one isn't really that much more difficult. Package managers are 100% optional.
- qbasic_forever 4y ago
  Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.
  - bombolo 4y ago
    I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the authors.
    - qbasic_forever 4y ago
      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.
moss2 4y ago
Yes (I'm not the guy who wrote that comment but I would very much like this)
- mike_hearn 4y ago
  It's not actually that hard for cross platform apps, at least. We do this in Conveyor and can build debs and apt repos, with inferred dependencies, even from Windows and macOS: https://conveyor.hydraulic.dev/7.2/outputs/#linux https://conveyor.hydraulic.dev/7.2/outputs/#linux It works by downloading the Ubuntu package index and using it to look up ELF dependencies, devs can also extend the inferred list with other package names if they like. The deb installs an apt sources file and public key so users can stay entirely in the GUI. The control scripts are auto-generated but can have extra code appended to them via the config file if the developer so wishes. It works pretty well. Conveyor is used primarily for cross-platform apps that use {Electron, JVM, Flutter, C++/Rust} and those don't normally have very complex Linux specific dependencies. Also, in practice Ubuntu and Debian and its various forks are close enough that package metadata is compatible in basically all cases. People do ask us for Flatpak sometimes. Probably RPM is a higher priority though. Those two get most Linux users, they're stable, there are portable libraries that can make them and they can package anything without code changes. Flatpak requires mastering a new file format and the mandatory sandboxing is guaranteed to cause problems that will end up in the support queue of the deployment tool.
wongarsu 4y ago
The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.
- Klonoar 4y ago
  This model doesn't necessarily work for software that developers don't want others shipping for them.
  - koolba 4y ago
    Or you end up with useless packages like ancient versions of nodejs sticking around for half a decade.
    - lelanthran 4y ago
      At which point was nodejs five years older than the distro it shipped on? Not being facetious, genuinely curious.
      - koolba 4y ago
        > At which point was nodejs five years older than the distro it shipped on? https://askubuntu.com/questions/1259840/why-an-old-nodejs-version-is-installed-on-my-ubuntu-machine https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve... Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release. So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.
        indymike 4y ago
        This is what is expected on LTS releases and is what is expected by people that highly value long term support releases. That said, I think modern security and modern software development practices have obsoleted a lot of the thinking behind LTS releases.
londons_explore 4y ago
There are plenty of projects to semi-automatically produce packages for a large number of distributions starting from just a git repo of the software to package. Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.
- dTal 4y ago
  What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc... 2) a standard format for declaratively describing how to build a package. Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.
  - rand_flip_bit 4y ago
    Congrats you just invented containers :P
    - dTal 4y ago
      Not sure how you figure that. Containers are completely orthogonal to both of my requirements, which again are 1) a globally canonical package namespace, and 2) tooling to convert some standard recipe file format into distro-specific recipe files (which would require point 1 to work).
  - account42 4y ago
    There are already many standard build specification formats: CMake, autotools, Meson. For each, most distro's package managers can build the software with very little configuration, e.g. Debian's debhelper will cover most standard build systems and Gentoo has eclasses that you just need to inherit in a package. I'm not sure that adding another makes things easier. Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ. For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.
lucideer 4y ago
I take your point (it's the general point many use to argue for Snap/Flatpak/Nix/AppImage/0install/Homebrew/&c.) but if you want to ensure you're not replacing per-distro-package-manager-fragmentation with completely-arbitrary-chaotic-package-manager-fragmentation there needs to be some unity & consideration for what users want in order to ensure they'll willingly subscribe to your system of choice. While I wouldn't call Flatpak "popular" with users per se, it's probably one of the least-worst alternatives that have come out. The horse Ubuntu has backed (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt), but that's not going to make the debate go away: it just strengthen's the argument to return to distro packaging.
- account42 4y ago
  > (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt) Care to expand on this? I'm not in Ubuntu-land but can't imagine how a service with an open protocol and multiple clients forces you onto Snap.
  - lucideer 4y ago
    I just mean distributing software exclusively through 1 channel (or at least only officially supporting 1). This wouldn't be the worst situation (devs needing to more time preparing myriad distribution formats is a valid problem) if the specific 1 channel being used wasn't a broadly resented channel.
nubinetwork 4y ago
Gentoo uses packages shipped in deb format all the time, its not just a debian or ubuntu thing.
api 4y ago
As someone who does this for a lot of distros (ZeroTier), I can say that it is hell and I understand why devs don't want to do it. Two specific examples: (1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not using the versioning scheme or naming convention. We're not doing it now but we may switch to statically linking this. (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages. So imagine (1) and (2) ad infinitum times a hundred little distributions and Debian forks and... it's completely untenable. Static linking solves many of the problems but that defeats some of the purpose of package management. We do it for all the major Debian and Ubuntu distributions by using a qemu-chroot based build farm that builds on each distribution+architecture combo with actual qemu binary emulation. It's over 200 gigabytes of chroots and takes two hours on a 64-core Threadripper to build all the artifacts. We tried cross compilation and had too many problems: it builds fine, seems to run fine, then users complain that some mysterious glibc symbol was missing on their system. We switched to building on actual chroots and most of those problems went away. Most of them. Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs." The only thing worse is Windows MSI installers and Windows drivers, though with those at least there's less platform variation so once you battle those horrors the result mostly works on most systems. Mostly. But whoo boy is the Windows installer system horrific. I shall quote Pinhead: "I have such sights to show you..." Apple is the easiest because they have less legacy baggage than Windows and only one "distribution." They do have some horrors around signing and notarization and we don't distribute in the Mac App Store (yet?). A major reason SaaS delivered through browsers is eating the world is the immense and totally unnecessary pain of distributing apps for major OSes. Even Apple is quite a bit harder than making a web site that you visit in a browser. All this pain is 100% the fault of OSes not caring about developer experience and in the case of Linux the multiplication of endless "vanity distributions" to no benefit to the community. If you want packages instead of tarballs of OSes, Linux distributions could (1) consolidate and (2) invest some time in the very boring totally un-sexy work of massive amounts of clean-up and standardizing things as much as possible. But it's more fun to make another vanity distribution I guess. You'll get it right this time and everyone will switch to your distribution.
pizza234 4y ago
The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; producing deb packages for different targets is not difficult. The last (only) breaking change across different targets I can remember was old graphic libraries (I think it was gtk2-based WxWidgets, removed in newer Ubuntu versions).
- manuelabeledo 4y ago
  > The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. This is one of the points they are missing with snaps and flatpaks. These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application? Snaps are an absolute nightmare in these scenarios.
  - PlutoIsAPlanet 4y ago
    > These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager. Although they do share tech, ostree, namespacing etc.
    - manuelabeledo 4y ago
      > Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. There are things that you just cannot run inside a container. Also, in cloud environments, default provisioning is not done with containers, which makes sense, but directly causes the issues I mentioned, e.g. Amazon provisioning SSM on Ubuntu Server instances.
simon_o 4y ago
Yes. Deal with it.
matheusmoreira 4y ago
> What you are really saying is you want all software developers to publish Debian packages That's exactly what I want. Developers and Linux distribution maintainers should be working more closely with one another instead of reinventing static linking with "snaps" or whatever just to avoid working with the community.

creshal 4y ago

The whole point of a distribution is that this job is done by the distributors, not the authors.

alkonaut 4y ago
Is there a distribution (or whatever one would call it - a Linux) where the aim is to not be managing the whole end-user system of OS+Apps, but just the OS. E.g. similar to Windows, or Android?
- drbig 4y ago
  There are operating systems - like FreeBSD - which have a very strong and clear distinction between the Operating System base and third-party software.
- dikei 4y ago
  For server there's Flatcar Container Linux, which only provide just enough to run containers. Everything else is provided by the container packager.
- qbasic_forever 4y ago
  Arch Linux is pretty faithful to shipping software exactly or as close as possible to as the upstream authors intended. It's on a rolling release which means you kind of get a firehose of nonstop major version updates though, whether you want them or not.
  - geokon 4y ago
    how does that work in practice？ upstream didn't build with all the dependencies at the same version as the latest in the arch repo. Nor are most upstream developers bumping all their dependency versions constantly if you're a big player like ubuntu/debian you can go to the authors/upstream and ask them to fix the program to work with their dependency versions (in say.. an LTS release). most would be glad to bc it's just something upstream needs to do once every couple years and doesn't need maintenance. If even thats too much and yyou want esomething even more handsoff/timeless then you make an Appimage. It'll work for ever With Arch youd need to constantly monitor the thing doesn't break？Are they just #yolo'ing dependency versions most of the time ？ (itd prolly work 99% of the time..)
    - creshal 4y ago
      In practice it works because GP is exaggerating. Arch does hold back library and/or program updates until they work together, or simply ships multiple major releases of libraries, and have a separate testing branch. Right now e.g. there's openssl (still at version 3.0.x, because nobody supports 3.1.x yet) and openssl-1.1 (1.1.x-y) to handle the rather slow migration of upstreams to the new major release.
- viraptor 4y ago
  Fedora Silverblue https://silverblue.fedoraproject.org/ https://silverblue.fedoraproject.org/ You're expected to run most apps as flatpaks.
  - curt15 4y ago
    I stopped distro-hopping a few years ago after landing on Silverblue a few years ago (back when it was still called Fedora Atomic Workstation). While it doesn't satisfy all use cases, I view it as a boring (in a good way) 80-percent solution that normally just works.
  - pch00 4y ago
    Silverblue doesn't get a lot of press but it makes a really solid desktop OS.
    - PlutoIsAPlanet 4y ago
      Fedora has always been quite bad at branding and making their distro appealing. It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc. Stark contrast to something like https://vanillaos.org/ https://vanillaos.org/
- creshal 4y ago
  No distribution forces you to use package managers for everything. Even before flatpak/snap, distributing (especially commercial) software as just archives or executable installers was/is perfectly possible. The caveat is, there's no common baseline for libraries. Graphics libraries, the libc itself, GUI widget libraries etc. will appear in different version combinations in different distributions, since they have different release schedules. So if you want to go the Windows/MacOS route and ship a readily compiled program for Linux, you have to vendor in a loooot more libraries, and they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.) Flatpaks/snaps try to solve this (poorly) by vendoring the entire kitchen sink and then some, which just creates more bloat and a worse DLL hell than Windows could ever have dreamed of. So using it for everything isn't really feasible still.
  - account42 4y ago
    > they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.) Simply don't vendor glibc and graphics drivers and you will be fine. Vendoring drivers doesn't make sense anyway as your application will be obsolete by the next HW cycle.
    - creshal 4y ago
      glibc breaks regularly, as does mesa occasionally, so it would realistically be required if you wanted win32-style 20+ years of backwards compatibility. And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly. And that sort of software doesn't really obsolete. Steam and GoG allow games to have a 10+ years long tail of slow but steady sales that don't really justify constant maintenance releases but still both let people enjoy good games (those don't really obsolete), and serve as advertisement for the developers' newer games.
      - 4y ago
- JohnFen 4y ago
  Slackware, perhaps? Honestly, if you just want the naked OS, you don't need a distro at all. Or just don't use the package manager.
  - alkonaut 4y ago
    I'm curious what a Linux would look like that behaved more like windows or android in the sense that there isn't such a blurry line between the OS and its applications. For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? This is basically the Unix "I'm not just an OS, I'm a platform for building and running C programs" heritage that isn't properly hidden I think.
    - creshal 4y ago
      We've reached the point where the C ecosystem has so given up on having a package manager that isn't Linux distributions that Microsoft added WSL and Docker(-compatible) Linux images are the most widespread distribution format. I don't think we can still figure out a way to decouple the two again, and without that, we can't really create a Linux environment that isn't a package manager with an email client. And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.
    - JohnFen 4y ago
      > in the sense that there isn't such a blurry line between the OS and its applications. Interesting. It never occurred to me that there's a blurry line between the two. It seems to me that there's a very hard line between the two. I'm not sure I understand what you're saying here. > For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? I'm confused by this question, so forgive me if this answer isn't really addressing it. A package manager is a convenience, nothing more. Using one means makes your life easier in a number of ways. But not using one isn't really that much more difficult. Package managers are 100% optional.
qbasic_forever 4y ago
Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.
- bombolo 4y ago
  I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the authors.
  - qbasic_forever 4y ago
    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.

moss2 4y ago

Yes (I'm not the guy who wrote that comment but I would very much like this)

mike_hearn 4y ago
It's not actually that hard for cross platform apps, at least. We do this in Conveyor and can build debs and apt repos, with inferred dependencies, even from Windows and macOS: https://conveyor.hydraulic.dev/7.2/outputs/#linux https://conveyor.hydraulic.dev/7.2/outputs/#linux It works by downloading the Ubuntu package index and using it to look up ELF dependencies, devs can also extend the inferred list with other package names if they like. The deb installs an apt sources file and public key so users can stay entirely in the GUI. The control scripts are auto-generated but can have extra code appended to them via the config file if the developer so wishes. It works pretty well. Conveyor is used primarily for cross-platform apps that use {Electron, JVM, Flutter, C++/Rust} and those don't normally have very complex Linux specific dependencies. Also, in practice Ubuntu and Debian and its various forks are close enough that package metadata is compatible in basically all cases. People do ask us for Flatpak sometimes. Probably RPM is a higher priority though. Those two get most Linux users, they're stable, there are portable libraries that can make them and they can package anything without code changes. Flatpak requires mastering a new file format and the mandatory sandboxing is guaranteed to cause problems that will end up in the support queue of the deployment tool.

wongarsu 4y ago

The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.

Klonoar 4y ago
This model doesn't necessarily work for software that developers don't want others shipping for them.
- koolba 4y ago
  Or you end up with useless packages like ancient versions of nodejs sticking around for half a decade.
  - lelanthran 4y ago
    At which point was nodejs five years older than the distro it shipped on? Not being facetious, genuinely curious.
    - koolba 4y ago
      > At which point was nodejs five years older than the distro it shipped on? https://askubuntu.com/questions/1259840/why-an-old-nodejs-version-is-installed-on-my-ubuntu-machine https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve... Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release. So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.
      - indymike 4y ago
        This is what is expected on LTS releases and is what is expected by people that highly value long term support releases. That said, I think modern security and modern software development practices have obsoleted a lot of the thinking behind LTS releases.

londons_explore 4y ago

There are plenty of projects to semi-automatically produce packages for a large number of distributions starting from just a git repo of the software to package. Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.

dTal 4y ago
What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc... 2) a standard format for declaratively describing how to build a package. Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.
- rand_flip_bit 4y ago
  Congrats you just invented containers :P
  - dTal 4y ago
    Not sure how you figure that. Containers are completely orthogonal to both of my requirements, which again are 1) a globally canonical package namespace, and 2) tooling to convert some standard recipe file format into distro-specific recipe files (which would require point 1 to work).
- account42 4y ago
  There are already many standard build specification formats: CMake, autotools, Meson. For each, most distro's package managers can build the software with very little configuration, e.g. Debian's debhelper will cover most standard build systems and Gentoo has eclasses that you just need to inherit in a package. I'm not sure that adding another makes things easier. Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ. For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.

lucideer 4y ago

I take your point (it's the general point many use to argue for Snap/Flatpak/Nix/AppImage/0install/Homebrew/&c.) but if you want to ensure you're not replacing per-distro-package-manager-fragmentation with completely-arbitrary-chaotic-package-manager-fragmentation there needs to be some unity & consideration for what users want in order to ensure they'll willingly subscribe to your system of choice. While I wouldn't call Flatpak "popular" with users per se, it's probably one of the least-worst alternatives that have come out. The horse Ubuntu has backed (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt), but that's not going to make the debate go away: it just strengthen's the argument to return to distro packaging.

account42 4y ago
> (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt) Care to expand on this? I'm not in Ubuntu-land but can't imagine how a service with an open protocol and multiple clients forces you onto Snap.
- lucideer 4y ago
  I just mean distributing software exclusively through 1 channel (or at least only officially supporting 1). This wouldn't be the worst situation (devs needing to more time preparing myriad distribution formats is a valid problem) if the specific 1 channel being used wasn't a broadly resented channel.

nubinetwork 4y ago

Gentoo uses packages shipped in deb format all the time, its not just a debian or ubuntu thing.

api 4y ago

As someone who does this for a lot of distros (ZeroTier), I can say that it is hell and I understand why devs don't want to do it. Two specific examples: (1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not using the versioning scheme or naming convention. We're not doing it now but we may switch to statically linking this. (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages. So imagine (1) and (2) ad infinitum times a hundred little distributions and Debian forks and... it's completely untenable. Static linking solves many of the problems but that defeats some of the purpose of package management. We do it for all the major Debian and Ubuntu distributions by using a qemu-chroot based build farm that builds on each distribution+architecture combo with actual qemu binary emulation. It's over 200 gigabytes of chroots and takes two hours on a 64-core Threadripper to build all the artifacts. We tried cross compilation and had too many problems: it builds fine, seems to run fine, then users complain that some mysterious glibc symbol was missing on their system. We switched to building on actual chroots and most of those problems went away. Most of them. Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs." The only thing worse is Windows MSI installers and Windows drivers, though with those at least there's less platform variation so once you battle those horrors the result mostly works on most systems. Mostly. But whoo boy is the Windows installer system horrific. I shall quote Pinhead: "I have such sights to show you..." Apple is the easiest because they have less legacy baggage than Windows and only one "distribution." They do have some horrors around signing and notarization and we don't distribute in the Mac App Store (yet?). A major reason SaaS delivered through browsers is eating the world is the immense and totally unnecessary pain of distributing apps for major OSes. Even Apple is quite a bit harder than making a web site that you visit in a browser. All this pain is 100% the fault of OSes not caring about developer experience and in the case of Linux the multiplication of endless "vanity distributions" to no benefit to the community. If you want packages instead of tarballs of OSes, Linux distributions could (1) consolidate and (2) invest some time in the very boring totally un-sexy work of massive amounts of clean-up and standardizing things as much as possible. But it's more fun to make another vanity distribution I guess. You'll get it right this time and everyone will switch to your distribution.

pizza234 4y ago

The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; producing deb packages for different targets is not difficult. The last (only) breaking change across different targets I can remember was old graphic libraries (I think it was gtk2-based WxWidgets, removed in newer Ubuntu versions).

manuelabeledo 4y ago
> The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. This is one of the points they are missing with snaps and flatpaks. These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application? Snaps are an absolute nightmare in these scenarios.
- PlutoIsAPlanet 4y ago
  > These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager. Although they do share tech, ostree, namespacing etc.
  - manuelabeledo 4y ago
    > Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. There are things that you just cannot run inside a container. Also, in cloud environments, default provisioning is not done with containers, which makes sense, but directly causes the issues I mentioned, e.g. Amazon provisioning SSM on Ubuntu Server instances.

simon_o 4y ago

Yes. Deal with it.

matheusmoreira 4y ago

> What you are really saying is you want all software developers to publish Debian packages That's exactly what I want. Developers and Linux distribution maintainers should be working more closely with one another instead of reinventing static linking with "snaps" or whatever just to avoid working with the community.