4 ms·

It may be unpopular but it's correct! Every language tries to re-implement the package manager, but it ends up breaking down as soon as you need to interact wi

It may be unpopular but it's correct! Every language tries to re-implement the package manager, but it ends up breaking down as soon as you need to interact with anything outside of that specific language's ecosystem. The only solution for interacting with the "outside" (other languages, toolchains, etc) is a system level, language agnostic package manager of some kind. Linux distros package management is far from perfect but it's still miles ahead of the alternatives! I very highly recommend people to learn how to write and create Linux packages if they need to distribute software. On Arch for example this would be creating PKGBUILDs, Gentoo has ebuilds, and other distros have something similar to these things.

Const-me 4y ago
> it ends up breaking down as soon as you need to interact with anything outside of that specific language's ecosystem. It works OK in nuget on Windows, due to the different approach taken by the OS maintainer. A DLL compiled 25 years ago for Windows NT stills work on a modern Windows, as long as the process is 32-bit. A DLL compiled 15 years ago for 64-bit Vista will still work on a modern Windows without issues at all. People who need native code in their nuget packages are simply shipping native DLLs, often with static link to C runtime. Probably the most popular example of such package is SQLite. > I very highly recommend people to learn how to write and create Linux packages if they need to distribute software. I agree. When working on embedded Linux software where I control the environment and don’t care about compatibility with different Linuxes or different CPU architectures, I often package my software into *.deb packages.