There are too many effing package managers. No, seriously – there are. If you look at a typical Linux server with a modern webstack installed on it, there’s easily 5 or more package managers available.
Who’s responsible for which one? The way I see it, there are 3 typical tiers of package managers, with one problematic zone that we need to address.
The Ops Tier
Every sysadmin knows how to keep their system up-to-date. We have the Fedora family with the yum package manager, Debian derivatives via apt, Arch has pacman, … every Linux family has their own major package manager. And every sysadmin knows about these, and how they’re used to keep the system updated.
On Linux, the amount of package managers we as “ops” need to know about is pretty limited and straight forward.
The Dev Tier
Enter the wild west. Most programming languages have one or more package managers.
In the PHP world, one of the older – but still used – package managers is pear. Pear is used to install common PHP classes server-wide.
In addition, in recent years PHP has seen the adoption of the composer package manager. This is far more flexible than pear, as it allows package (typically: PHP classes and the occasional system binaries) to be installed locally, in a local path. composer also allows for packages to be installed system-wide (ie: drush), but most use is for local classes, specific to the project.
Composer uses upstream repositories (like cvs, git, tarballs, …) to install packages, but a developer can also use plain git submodules for dependency management.
The Node community has npm, Puppet-folks have librarian, Ruby has bundler, …
These tools are more obvious, they are the responsibility of the developer. If urgent updates are needed, the developer should check for compatibility and install/update the required package.
The Middle Ground (DevOps?)
Between the Ops and Dev package managers lies a more difficult grey area. It’s the area that requires more communication between Dev + Ops and a lot more coordination.
For instance, the PHP world also has a package manager called pecl. Pecl is a package manager that downloads PHP extension source code and compiles it into the working PHP extension. The pecl package manager is often run with root privileges and the PHP extension is installed server-wide and included in the /etc/php.d/ .ini configurations.
But these kind of installations are mostly a one-time installation. Since pecl is one of those typical lesser used/third party package manager, extensions are often installed once and never updated.
The same goes for the Ruby world, with packages installed via gem or in Python’s case via pip. Add to this the ability to run multiple versions of Ruby with rvm, each having their own gems, and it can quickly become a problem of responsibilities.
Who’s task is it to keep the system-wide installed additional packages up-to-date? Updating a pecl/gem/pip package can have serious impact on the application.
Typically, those kind of packages are only updated when A) a developer reports a problem or B) a security vulnerability is reported and the update is required, regardless of application compatibility (which can be fixed in a later stage).
Clear separation of concerns
That grey area is problematic. Ops know their package managers, Dev know of their own. But those packages that have a direct impact on the application *and* require root-level installation privileges to install/update, will come back to hunt us one day.
Ruby’s method of locally installing gems via rvm is a solid approach, but how often are those gems updated by developers? For PHP I think it’s even more complex, as custom extensions need to be loaded in the php-fpm master process, typically started/stopped/managed by system administrators – not developers. There’s no easy way to inject custom PHP extensions as a developer, without Ops-interventions.
If anyone is looking for a new open source idea, I think package/repository management is an area that can use a lot of loving and has a lot of potential. The most difficult part is having all communities (Linux distributions + developer communities) to come together on this.