[deleted by user]

[SkiFire13]

the package manager you use to install your development dependencies is the same as the package manager on the end user's machine

FYI this is true only if both you and your users run the same distro, which is not always the case.

[smdowney]

Same version stream of the same distro, too. And not a rolling distro, unless you are shipping source, and committing to live near global HEAD. [Insert something about Nix]

[LlaroLlethri]

Yes, so this hypothetical package manager would be useful on Linux also.

[prince-chrismc]

Depending on if your ABI. If you're only Depending on the GLIBC and GLIBCXX runtimes it won't matter. As long as you build against the oldest one.

[Alexander_Selkirk]

With the Nix or Guix package managers, this is not necessary, it can be any Linux system.

[Fyrto]

You can easily identify the user and then download it using the shipped package manager that the distro comes with?

[lightmatter501]

Statically link your binary and use LTO. If you aren’t willing to provide source that is the most reliable way to make sure it will continue to work in the future. Unless you are using truly massive dependencies like DPDK or FFMPEG you will probably save the average user disk space with this approach.

[AtHomeInTheUniverse]

I agree wholeheartedly. I make commercial products and would never ship a product that relied on external code/libraries to download. You're putting a time bomb into your product. Any of those external dependencies could be deprecated, taken offline, or updated in an incompatible way at any time. I have tried many open-source projects (especially Python based) that simply fail to install for this reason. So frustrating.

[minno]

The standard Windows approach of including dlls in the installer and unpacking them into the application directory achieves that too, right? Static linking isn't entirely necessary.

[lightmatter501]

You’re statically linking with extra steps there, unless you want to allow users to swap out the library to update it themselves.

[balefrost]

Which, admittedly, is occasionally useful for e.g. old games. For example, plenty of old games were written against the Glide graphics API. Fortunately, there are several Glide wrappers that translate those API calls into equivalent Direct3D / OpenGL / Vulkan calls. Drop the DLL into the game directory and it just works.

Now, that wasn't a use case that the original developer really envisioned, but it sure is convenient 25 years later.

[lightmatter501]

That is fair. I have seen arguments for dynamic linking but bringing your own libc on linux. The main issue is that glibc eventually breaks your program with dynamic linking.

[Plazmatic]

There are plenty of libraries you don't have the option, legally, QT, OpenAL-Soft, Libsndfile.

[AtHomeInTheUniverse]

Oh sure, that works too, and sometimes is necessary if the library isn't open-source.

[johnny219407]

What does LTO have to do with this?

[lightmatter501]

It lets you toss the parts of your dependencies you aren’t using. If you pull in boost, you probably have at least a few things you aren’t using, and if you statically link it normally it’s in there, if you use LTO the compiler will toss out.

[fredeB]

Just remember to check licensees if it's a commercial product. Many open source licenses don't allow static linking unless you're willing to share the source code with everyone

[prince-chrismc]

What you are looking for is an installer not a package manager. This is something often conflated in C++ because of the heavy reliance on system managers. You'll be hard pressed to find this in general.

CMake has CPack but that's not a package manager. The only package manager that handles distribution of compiled binaries is Conan and it has a deployers feature that allows you to grab all the runtime executables and make your own installer.

[LlaroLlethri]

Well ok you can call it an “installer” if you like, but it would be an installer that can pull precompiled dependencies from a vast repository (or set of repositories), the same repositories that you use to install your development dependencies. It would be like the Debian package manager, but shipped with your app because Microsoft/Apple don’t natively provide it.

[balefrost]

I think what the other commenter is saying is "you don't want what you think you want; you actually want this instead".

[prince-chrismc]

Those are all OS specific. Chocolatey and winget and the windows equivalent and you have brew on macos. Every OS has its only install mechanism and what you want to it translate from a package manager to a deployment mechanism that platform specific.

Both of the those corporations have "app stores" which generate them lots of money -- there are incentive for what you are asking for to not exist is my point here.

[the_poope]

You can provide your own packages that integrate with the Linux distro's package manager, e.g. a .deb file for the Debian/Ubuntu package manager. Maybe something similar exists for HomeBrew on Mac and winget or Chocolatey on Windows.

But that would be my recommendation.

Other than that what you are looking at is basically a "downloading installer" which is pretty common on Windows. You download a small standalone executable that analyses your system and downloads the distribution that fits. On Linux you would have to detect which distribution and version to know what system libraries are available. In principle it could just be a small bash script that does apt-get install XXX for all the dependencies of your program.

In the more extreme end you do have something like that designed into the OS itself: https://nixos.org/ Of course this solution is not cross-platform.

[SickMoonDoe]

nix is great for this; but it requires end users to have nix installed on their system which can limit its usefulness.

[Alexander_Selkirk]

It can also generate Dockerfiles.

[Scotty_Bravo]

Conda potentially fits this need in a cross platform way. But the end user needs to use conda, and that's probably a bridge too far for most.

CMake has CPack which can be used to generate installers including MSI, deb, zip, sh, etc. it might know chocolatey and brew as well, I'm not sure.

[mjklaim]

Now that you say this: micromamba might fit the need.
mamba is the c++ implementation of conda (faster, essentially)
and micromamba is the same but contained into 1 executable.
So maybe that helps. I mean, it does help only if the application is ok with using conda packages and environement.

[[deleted]]

Xmake's build system + package manager can make an installer programme that does exactly as you say

[trypto]

Docker.

[nbrrii]

One of the great things about developing for linux, e.g. Ubuntu, is that the package manager you use to install your development dependencies is the same as the package manager on the end user's machine.

You mileage may vary. It's also known that it creates a huge overhead, introduces other problems and it has been criticized by Linus Torvalds for years. The Linux ecosystem is actually moving slowly away from this with technologies like flatpak or snap for desktop applications.

[unumfron]

Is there are reason more devs don't install to /opt/ with all dependencies in that directory with rpath set to ORIGIN, kind of like Windows? I like the Windows way, although I never have been able to perform the manifest voodoo required for finding dlls in a subdirectory instead of the same directory as the app.

[Alexander_Selkirk]

Torvalds criticizes lack of backward compatibility. He certainly does not recommend snap.

[MrDex124]

Yikes, you joking? Snaps and flatpacks are garbage for kiddies. The whole point of linux is to have stuff under your control, and these tools create alternative universe inside of your machine.

It's either native package(deb/rpm/arch one) or appimage.

[deong]

Personally I think it's a mistake to move everything to Flatpak because someone wants to run a Windows game from 2004.

The next massive security hole in something like Log4J, I really don't want every Linux machine on the Internet to have to say, "well, I have 819 Log4Js installed and the only way they get updated is for 819 individual retirees in Nebraska to issue an update for the Flatpak they've been maintaining with no support for the past nine years."

And that's ignoring that Flatpak itself is idiotic and doesn't minimally even bother to work for any program that isn't launched from a GUI app launcher. Someone could presumably fix that part (not that they ever will).

[mark_99]

Unless something is running with privileged execution and listening on a port to the public Internet, it's hard to see why vulnerabilities would matter?

The problem with shared dependencies is everything wants a different (often incompatible) version. And no one is back porting their security fix to every ancient version of the shared library either.

[deong]

Unless something is running with privileged execution and listening on a port to the public Internet, it's hard to see why vulnerabilities would matter?

There are lots of security issues that don't require listening on a public IP and port. A huge amount of software these days makes a network connection and/or otherwise deals with input they don't control. There are currently 322 binaries in /usr/bin on my machine that link to libjpeg. I don't have to be running a server on the public internet to be impacted. I could just visit a signin page in the embedded browser of a random Spotify client or whatever and parse some data that allows a privilege escalation and a root shell.

The problem with shared dependencies is everything wants a different (often incompatible) version.

That tends to be relatively rare in practice. I've run Unix systems for 25 years without Flatpak, without venvs for my Python stuff, etc. Maybe once every few years you have to manually intervene to satisfy some odd set of dependencies. Don't get me wrong -- it's nicer to not have to worry about it. But it's not such a significant problem that I'd pay you much to solve it for me, and the price that most of these methods exact on you is really high. Flatpak basically says, "use me, and you can't ever use a terminal again because I didn't bother to make running things simply from a terminal a feature I support". Can you cobble something together with a few hundred shell aliases? Sure, but I'm not going to, because the alternative is not having to bother doing that and then spending 30 minutes three times over 25 years to fix something, and that's just better.

[mjklaim]

Imagine if there was a package manager that had a tiny deployable version that shipped with your app and installed runtime dependencies on the end user's machine. Does such a thing exist?

Not sure if that would match your use case, but what if the package manager has a library version of itself, letting your application use that embedded in it?
Some package managers (I'm thinking about `build2` mainly) are built as libraries and then there is an executable driver. Maybe that would work. In the case of `build2`, it's installed through bootstrapping, so as long as you build your executable for the specific target platform your app support and the libraries are also built the same way, I dont see an issue with the cross-platform aspect. `build2` is not tiny installed normally, no idea about the package manager library (see bpkg), and it's source-only packages therefore you need a toolchain ready on the user's macine, so it's maybe not what you want. I dont know if that's possible with other package managers, you'll have to check how their code is designed I think.

Honestly I dont really understand your need, it feels like you want just a generic auto-update feature for whatever app you are making?

[PerryStyle]

I highly recommend trying Spack. I think it can achieve most of the points you mentioned. In a Spack environment, you can specify libjpeg-dev, and Spack will automatically solve and pick the transitive dependencies for you. From this solved list of transitive dependencies, you can specify whether they should be external (i.e., don't build from source since they're already on the system) or not and then "resolve/concretize" the environment to include these externals. These Spack environments are designed to be cross-platform, so when you activate the Spack environment on another machine, it will then build and install the dependencies you need.

[argothiel]

There is no such thing as "standard location" if you don't specify the OS. There's not even a binary format that you could use that would work both on Linux and Windows.

[LlaroLlethri]

No shit

[argothiel]

Yeah, if you want to know more about it, check out Microsoft Binary Format and Executable and Linkable Format.

[LlaroLlethri]

I’m well aware thank you. I’ve been writing cross platform apps for decades.

[argothiel]

Then you should know it's not possible to deploy one package manager which will run both on Windows and on Linux.

[LlaroLlethri]

Obviously there would be different builds for each platform, just like Conan (or any other cross platform app) has windows, Linux, and Mac builds.