News for hackers. Stuff that matters.
Re:Thoughts on a Container Native Package System by vezzy-fnord on Wednesday July 01, 2015 @04:02PM (#9814752)
This seems like a roadblock that is rather inherent to the app container model of making images of host OS subsystems partitioned into their own namespaces.

I thought that the idiomatic usage was not to treat them as distros, but as immutable images that you simply tear down and provision when a major system state change transaction needs to be performed?

Package introspection and sharing seems like something people would run a CM or task runner on the containers for. Hence the whole move to build large orchestration suites for them.

Not sure what is exactly meant by "order dependence" in this context.

Package manager cruft is just bad resource management, or sometimes even deficiencies in the PM itself.

Re:Thoughts on a Container Native Package System by jbeda on Wednesday July 01, 2015 @04:10PM (#9814794)
Immutable images are the name of the game. Any sort of surgical update to image A would result in image A-prime.

Any sort of orchestration system will help to run containers and will know what images you are running but not which packages you are running inside those images.

With something like this a cluster admin could find all the containers across a 10k node cluster are running an unpatched version of openssl. Or could block running containers that are using unapproved packages.

"Order dependence" is the fact that Dockerfile is stictly linnear -- even when 2 steps won't interact in any way. It makes caching and reuse more difficult.