[scrollaway]

Reposting an old comment of mine on the subject::

The path to a standard package manager starts with a standardized protocol for package management.

A service protocol that is able to serve a repository of packages over http and ftp. A client protocol that can keep track of installed packages and can index, search and look for updates on installed packages.

Split package management into layers and only try to standardize bit by bit. People will never agree on deb vs rpm. People will never agree on using json vs python vs Makefile vs ruby vs shell vs whatever else - they'll always want their most familiar language for their package manager, which in domain-specific packaging means the domain-specific language.

So don't try to standardize those. Standardize the rest. Give us the protocol that can power all of this and increase interoperability. Separate the repository layer, the package format (deb, rpm), the packagefile format (setup.py, Makefile, PKGBUILD) and the package manager (interface: yum, apt-get, aptitude, pip, npm) from the rest of the protocol.

Make this potentially usable for things such as browser extension repositories, android package management, vim bundles and what not.

Someone please work on this. I'd do it but it just occured to me I have to clean my oven.

[k_]

Well, since it's an old comment your oven should be clean by now :)

[grosskur]

I'm working on something along these lines:

https://www.packagelab.com/

The idea is to have a common UI and REST API for building packages and managing repositories across packaging toolchains. Right now it supports rpm+yum and deb+apt. Packages are built in isolated Linux containers using Heroku's buildpack interface. (Would love feedback from anyone who's interested in beta testing.)

Also, have you seen the Omaha protocol?

https://code.google.com/p/omaha/wiki/ServerProtocol

It's used by a lot software, including Chrome and ChromeOS. Recently, CoreOS has built infrastructure with it and they offer a SaaS product for rolling updates. I think they're planning on using it to update Docker containers, too:

https://coreos.com/products/coreupdate/

[scrollaway]

I'll send you an email.

[_pmf_]

> Someone please work on this.

The only result will inevitably be that we'll have yet another package manager.

[scrollaway]

You completely misunderstand the point. "Another package manager" doesn't matter. People can and should use the package manager of their choice (why should I break pip?). The point is to have common ground between all package managers.

[jessaustin]

Could you talk about the advantage(s) you perceive of a "common ground between all package managers"? After using npm a bit I think scripting hooks in a package manager that can call other package managers enables many good things.

[scrollaway]

Well, for one thing, new package managers could be implemented without having to worry about the infrastructure. The server software could be shared between all linux distributions and would be applicable for any sort of "bundle server"; think game addons, firefox/chrome extensions, skins for your favourite software and what not.

[vertex-four]

One is that you can easily specify dependencies on packages not written in the language your package is written in, in a way that's machine-readable. Imagine if I could do "npm install some-framework" and it'd automatically build and install the relevant versions of node.js and MongoDB as well.

[jessaustin]

This is what I meant by "scripting hooks". I have something like the following in package.json for various projects:

  "devDependencies": {
    "bower": ">=1.3"
  },
  "scripts": {
    "postinstall": "bower install"
  }

This way I never need a global install of bower, nor do I ever really need to use it directly. I don't see why something similar couldn't be set up for any other npm-able package manager or build tool. A bit of googling seems to indicate that npm can update node using e.g. the "n" module. That module or another like it can of course be a dependency in package.json.

[vertex-four]

This isn't machine-readable, for a start - I can't see what your package actually depends on without reading through your postinstall script. I also can't write a script to convert it automatically to a .deb or a NixOS package or whatever else, because I can't figure out what its dependencies are. I can't easily say "I want this package and all its dependencies on a DVD".