[monkey26]

Docker as a package manager somewhat matches my use, and I think it does its job well. As the packager, I can just create one "package" that any Linux distribution running Docker can install, instead of creating packages for multiple versions of many different distributions.

[philips]

I think that container images will replace traditional package management in many cases. Package management in Linux has given us many great things:

1) Easy global mirroring of software using "boring" protocols like http and ftp

2) Cryptographic signing of the software so we can trust mirrors and systems that put users in control of who to trust.

3) Human significant package names that are easy to pull onto a host e.g. `apt-get install $name`

Where package management broke down:

1) Package collisions e.g. If I want to install a new custom build of python it replaces the host version and everything may break. The python3 v python2.6 problem.

2) Dependency namespacing. e.g. If I want rely on a non-official mirror to ship me whizbang project X they could also replace my libc by adding it to the repo because the names and versions collide.

Making sure that we hold onto the good three properties of package management while fixing the two problems is important for Linux moving forward. The last 15 years of Linux was dominated by the centralized package management system and a ton of hacks have developed to work around it when you need a new package or want to install custom software. This is why I spend so much time working on container image specs like appc and oci; I hope we can arrive at a good container image format for the next 15 years that everyone can rely on.

For examples see slide 6 forward here: https://speakerdeck.com/philips/rkt-and-the-need-for-the-app...

[takeda]

> 1) Package collisions e.g. If I want to install a new custom build of python it replaces the host version and everything may break. The python3 v python2.6 problem.

I'm sorry, but you hit my pet peeve when you used python as example. Python was written in a way that you can have multiple versions installed side by side and they all can work without problem. If you have a python3 package that is uninstalling python2.6 then its author screwed something up and I would be afraid to use it at all.

> 2) Dependency namespacing. e.g. If I want rely on a non-official mirror to ship me whizbang project X they could also replace my libc by adding it to the repo because the names and versions collide.

Is that still an issue? Zypper in OpenSuSE is quite smart and for each package it remember which repo it is from. It tries to satisfy dependencies without changing vendor, and prompts if only way to satisfy dependencies is to change vendor.

That said if an application requires different version of glibc much better would be to compile it statically, but even then glibc supposed to match your kernel version so you're still risking some incompatibilities.

[XorNot]

Static glibc doesn't work anymore. If you need the internet then you'll be pulling in the nss plugins anyway.

[davexunit]

GNU Guix is a package manager that solves those 2 problems while not sacrificing the 3 good properties. It also offers additional nice features like unprivileged package management, transactional upgrades/rollbacks, full system configuration management, and a tool that can be used like a language-agnostic virtualenv. Built-in Linux container integration is also on the way.

https://gnu.org/s/guix

[takeda]

What language is it in, why not use packaging from the language itself. It would be more likely to work across many different OSes not just Linux.

If it's a binary, why not compile it statically? That way it's a single file and it also will perform faster (using shared objects has overhead)

[philips]

Packaging in the language itself ranges from difficult to impossible for most non-trivial apps. Popular runtimes like python, node, and ruby have many extensions and packages that rely on C and share libraries. Because of that a compiled binary package will not be portable between machines or require that the machine you deploying to have a working compiler to build the C package from source. I have seen vast amounts of engineering effort invested into porting C code to slower "native" code just to make packaging work. With containers you can avoid the mess of trying to share the `/` filesystem namespace with the host and concentrate on getting your application working on a chroot that is portable between Linux kernel systems.

I 100% agree with the compile it statically thing. This is what many major internet properties likes Google do and I would argue part of why Go is so popular. But, it is hard for the vast majority of applications that expect to open files for assets and lack build systems for static compilation.