4 ms·

That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a deve

by imiric 1y ago

That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to influence distro maintainers to their will, since no distro will want to miss out on carrying such popular packages. So vendoring is in practice the only sane choice for smaller teams and projects. Besides, distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. It exists in this weird unspecified state that can technically be useful for end users, but is completely useless for developers. Are they supposed to develop on a specific distro for some reason? Should it carry sources or only binaries? Is the dependency resolution the same for all languages? Should language tooling support them? It's an entirely ridiculous practice that should be abandoned altogether. Yes, it's also silly that every language has to reinvent the wheel for managing dependencies, and that it can introduce novel supply chain attack vectors, but the alternative is a far more ludicrous proposition.

skydhash 1y ago
You do not depends on a package, you depends on its API. Implementation details shouldn't matter if behavior stays the same. Why do you care if the distro reimplemented ffmpeg or libcurl, or use an alternative version built with musl? Either the library is there or it's not. Or the minimum version you want is there or it's not. You've already provided the code and the requirement list, it's up to the distro maintainer or the user to meet them. If the latter patch the code, why do you care that much? And if a library have a feature flags, check them before using the part that is gated.
- deleted 1y ago
  [deleted]
- imiric 1y ago
  There's no guarantee that software/library vX.Y.Z packaged by distro A will be identical in behavior to one packaged by distro B. Sure, distro maintainers have all sorts of guidelines, but in reality, mistakes happen, and there can be incompatibilities between the version a developer has been testing against, and one the end user is using. Relying on feature flags is a pie in the sky solution, and realistically developers shouldn't have to be concerned with such environmental issues. Dependency declarations should be relied on to work 100% of the time, whether they're specified as version numbers or checksums. Since they're not reliable in practice, vendoring build and runtime dependencies is the only failproof method. This isn't to say that larger teams shouldn't support specific distros directly, but my point is that smaller teams simply don't have the resources to do so.
  - skydhash 1y ago
    But why do you care that much about how the user is running your code? Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you? You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code? Even the ones you do not own?
    - imiric 1y ago
      It matters because as a developer I'll get support requests from users who claim that my software has issues, even when the root cause is unrelated to my code. If I explicitly document that I support a single way of deploying the software, and that way is a self-contained artifact with all the required runtime dependencies, which was previously thoroughly tested in my CI pipeline, then I can expect far less support requests from users. Again, this matters a lot to smaller projects and teams. Larger projects have the resources to offer extended support for various environments and deployment procedures, but smaller ones don't have this luxury. A flood of support requests can lead to exhaustion, demotivation, and burnout, especially in open source projects and those without a profitable business model. Charging for support wouldn't fix this if the team simply doesn't have the bandwidth to address each request.
skydhash 1y ago
> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software. If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is about the user's system, not yours. When I want to run your code, you don't have to say: Use flatpak; Use docker; Use 24.1.1 instead of 24.1.0; Use $THING
- marcosdumay 1y ago
  It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching that flies under the radar of the upstream developers. Instead, the GPs proposal of vendoring the dependencies solves that problem, without breaking the compilation, and adds another set of issues that may or may not be a problem. I do argue that it's a good option to keep on one's mind to apply when necessary.
  - skydhash 1y ago
    > It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. That is not what it's being asked. As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1). But a lot of developers want to be maintainers as well and they want to enforce what can be installed on the user's system. (And no I don't want docker and multiple versions of nginx)
    - marcosdumay 1y ago
      > That is not what it's being asked. From whom? You seem to be talking only about upstream developers.

by imiric 1y ago

skydhash 1y ago

You do not depends on a package, you depends on its API. Implementation details shouldn't matter if behavior stays the same. Why do you care if the distro reimplemented ffmpeg or libcurl, or use an alternative version built with musl? Either the library is there or it's not. Or the minimum version you want is there or it's not. You've already provided the code and the requirement list, it's up to the distro maintainer or the user to meet them. If the latter patch the code, why do you care that much? And if a library have a feature flags, check them before using the part that is gated.

deleted 1y ago
[deleted]
imiric 1y ago
There's no guarantee that software/library vX.Y.Z packaged by distro A will be identical in behavior to one packaged by distro B. Sure, distro maintainers have all sorts of guidelines, but in reality, mistakes happen, and there can be incompatibilities between the version a developer has been testing against, and one the end user is using. Relying on feature flags is a pie in the sky solution, and realistically developers shouldn't have to be concerned with such environmental issues. Dependency declarations should be relied on to work 100% of the time, whether they're specified as version numbers or checksums. Since they're not reliable in practice, vendoring build and runtime dependencies is the only failproof method. This isn't to say that larger teams shouldn't support specific distros directly, but my point is that smaller teams simply don't have the resources to do so.
- skydhash 1y ago
  But why do you care that much about how the user is running your code? Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you? You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code? Even the ones you do not own?
  - imiric 1y ago
    It matters because as a developer I'll get support requests from users who claim that my software has issues, even when the root cause is unrelated to my code. If I explicitly document that I support a single way of deploying the software, and that way is a self-contained artifact with all the required runtime dependencies, which was previously thoroughly tested in my CI pipeline, then I can expect far less support requests from users. Again, this matters a lot to smaller projects and teams. Larger projects have the resources to offer extended support for various environments and deployment procedures, but smaller ones don't have this luxury. A flood of support requests can lead to exhaustion, demotivation, and burnout, especially in open source projects and those without a profitable business model. Charging for support wouldn't fix this if the team simply doesn't have the bandwidth to address each request.

skydhash 1y ago

> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software. If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is about the user's system, not yours. When I want to run your code, you don't have to say: Use flatpak; Use docker; Use 24.1.1 instead of 24.1.0; Use $THING

marcosdumay 1y ago
It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching that flies under the radar of the upstream developers. Instead, the GPs proposal of vendoring the dependencies solves that problem, without breaking the compilation, and adds another set of issues that may or may not be a problem. I do argue that it's a good option to keep on one's mind to apply when necessary.
- skydhash 1y ago
  > It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. That is not what it's being asked. As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1). But a lot of developers want to be maintainers as well and they want to enforce what can be installed on the user's system. (And no I don't want docker and multiple versions of nginx)
  - marcosdumay 1y ago
    > That is not what it's being asked. From whom? You seem to be talking only about upstream developers.