Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

Parent Full thread

The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development.

Package managers for development allow things such as installing multiple versions of a library, creating "sandboxes" with specific versions of libraries, and sometimes they are also the de-facto build system for a language.

The OS package manager isn't doing the same job and has very different requirements. Not all libraries (especially ones that are usually built statically or header-only) end up in an OS package manager. Typically OS package managers don't bundle any libraries that are not required by one or more of applications in the package repository.

So no, an OS package manager doesn't cut it for C or C++ development. They don't ship all the libraries and they can't do all the things you need for serious development.

As a C and C++ developer, this pisses me off constantly. Even though most libraries are easy enough to fetch these days with Git, there's no standard way of configuring, building and installing them. And no OS package manager has ever been able to provide all the libraries I need.

(Note: my frame of reference is experience with UNIX-like systems such as Linux and the BSDs, and even MacPorts on OS X.)

  The operating system package manager is supposed to
  provide packages for libraries that are required to
  run the rest of the operating system. Not libraries
  you need for development.

Distro repos do provide many of the packages you need for development because you need to be able to compile all of the C++ applications and libraries in the distro repo, of which there are many.

  Package managers for development allow things such as
  installing multiple versions of a library, creating
  "sandboxes" with specific version

Distro repos often include multiple versions of libraries because not all of the crucial applications and libraries in the repo are upgraded at the same speed.

  The OS package manager isn't doing the same job and has very
  different requirements. Not all libraries (especially ones that
  are usually built statically or header-only) end up in an OS
  package manager. Typically OS package managers don't bundle
  any libraries that are not required by one or more of
  applications in the package repository.

Fair enough, and for this reason a language-specific PM will most likely have more libraries available, so I concede that point. However, I seriously doubt that a single group of people could be better at providing packages for all the major combinations of kernel, distro, and CPU architecture than the collection of distro groups. Just imagine how difficult that would be!

C++ is different because it is very intertwined with the system. For D it makes sense at this point because it doesn't have the existing distro PM support that C++ does. Once crucial parts of the system starts depending on D the situation might change.

> Distro repos do provide many of the packages you need for development because you need to be able to compile all of the C++ applications and libraries in the distro repo, of which there are many.

I think it's more along the lines of the distro's package manager's responsibilities should be different from the language's PM. Although I do find myself in agreement with you that the distro's PM is sufficient for C/C++

Yes, a distro package manager can partially solve this issue but there are some corner cases where this fails. Though I partially agree with you: my OS package manager can provide me with the C and C++ libs I need most of the time.

To name a C++-specific pain in the ass: Boost. The Boost libraries make minor, incompatible changes every now and then (which is good), requiring applications that use Boost to either specify a certain version that they can work with or bundle the Boost libraries with the application source (which is bad).

And "development" package manager should be able to deal with the situation above, but distro package managers don't really work here. There are several libboost-foo-1.xy.z packages available but it may be that none of those will work with a certain application you're trying to build (either too old or too new).

This situation is handled by development package managers by pinpointing the exact version (or range of versions) of a library an application depends on. This also allows specifying compiler/interpreter version(s) an application works with. Some of my projects depend on features that are only available in recent GCC versions (__builtin_shuffle), but that requirement can only be informally specified in the README, nothing enforces it (leading to unnecessary bug reports).

This is also what git submodules does but without a standard build system, it only solves half of the problem (and may create new problems).

I think you and I can both agree that this situation is less than ideal. Using just one package manager application should be enough, there's a lot of overlap between what a distro package manager and a development package manager do. And it's a huge waste of engineering resources to maintain language-specific package managers such as pip/gem/cabal/cpan.

"Next generation" package managers such as Nix and GNU Guix should be able to address these issues, but they are yet to be widely adopted. Unfortunately those applications are based on less-than-mainstream languages (Haskell and Guile Scheme, respectively) which might scare away potential adopters.

Reply on news.ycombinator.com