Hacker News Reader

Comment by eyko | Hacker News Reader

> Trouble starts the minute you start relying on commands like this:

    sudo apt-get install mypkg

So what's wrong with `sudo apt-get install mypkg=<version>`?

View on HN

Do you do this every time? Must be cumbersome, there's no equivalent of Gemfile.lock and bundler for apt-get, is there?

(Or is there? Serious question)

https://help.ubuntu.com/community/PinningHowto

My guess is that apt pinning/holding predates Gemfile.lock by quite a few years :)

This and Ansible are non-answers to me.

The functionality of bundle install and bundle update are not replicated by apt pinning or holding. How do you roll back a bad update to your pinned packages? Put back the old Gemfile.lock and bundle (again)? Does that really work?

I guess I don't really use Ansible so I don't know, but it's very easy to roll back a bundle update if you keep your Gemfile.lock in revision control too. I've used apt pinning before though, and I'm quite sure rollback of a package update that has a dependency conflict with the old version is not as easy.

I've used apt pinning before though, and I'm quite sure rollback of a package update that has a dependency conflict with the old version is not as easy.

Aptitude has always handled that just fine for me, downgrading the dependencies as well if needed.

You're still losing the information about what you had pinned before by unpinning, unless you can dig it out of dpkg.log after the fact. This is almost nothing like having Gemfile.lock and committing it to the project code repo, saving each changeset after every "bundle update".

It is an issue with the package manager, like the python/virtualenv guy suggested, apt can't support keeping parallel versions installed at the same time and linking in the locked version into each separate project that needs a specific version. The conflicting versions do conflict. This is not a problem for bundler, since a given project is not likely to need two separate conflicting versions in a single bundler exec.

There is no "project" concept at all in dpkg. You just have to maintain wholly separate environments for those conflicting dependencies, on separate machines, if they show up in cases where you really need both versions.

Or work with containers instead, which is arguably not really a different solution than already proposed.

You're still losing the information about what you had pinned before by unpinning, unless you can dig it out of dpkg.log after the fact.

Oh, that's why I mentioned Ansible in my previous comment. I have a version controlled file with:

  - apt: pkg=lib1 version=11.6
  - apt: pkg=app version=33
  ...

To rollback, I can just revert to the right commit and re-run ansible-playbook.

As for multiple parallel versions installed, sure you can. All you need to do is packaging them using different prefixes. What you can't do is blindly use packages from the main repos; those are built to be used to support the OS programs, not yours. But even those are often made to have multiple parallel version: I have python 2.7 and python 3 installed, both from Debian's main repo.

Usually configuration management tools like Ansible are used.

Well... In python, we do that the first time around. After that, we get a file saying exactly what version was installed for future installs. It'd be nice to have something like that for package management... Thinking about it, the issue of drifting seems to be more of a problem with the packaging system, than ssh...

Instead of using public repos and pinning the version you want from them, you can run your own repo and import the versions you want. Running your own mirror is a good idea anyway, and there are tools like http://www.aptly.info/ which simplify the process of locking packages in environments.

Nothing in the heat of the moment. The problem comes six months down the road when something happens and you need to build that box again(horizontal scaling, box death, whatever). Your provisioning script is still point at correct version - 1.

The new box will be brought up to netboot via PXE, which runs whichever automated installer your OS uses, including assigning IPs, partitioning the drives, etc. The script then points to the proper configuration management system you use, which chooses the proper script for whatever the box is -- web frontend, database, etc -- and then finishes out the install. You're never a version behind, because your installer is maintained with every other bit of configuration. A good deployment system means new boxes are never out of date.

mypkg-v1 depends on libsomething. mypkg-v2 doesn't depend on it anymore. Now you have machines with libsomething leftovers.

Another issue with debian packages is that dpkg essentially removes the old package before installing the new one. If you're packaging assets served by nginx/apache then there is an availability issue in the mean-time.

mypkg-v1 depends on libsomething. mypkg-v2 doesn't depend on it anymore. Now you have machines with libsomething leftovers.

That's what "apt-get autoremove" is for.

Both problems are only an issue if you don't have automated deployment or more than one server. Otherwise, you can simply drop a service from a load-balancer / cluster when doing an upgrade and add it back in once it's back up and passing health-checks.

Config drift can be avoided by using the same process to create new VMs and delete old ones, which is also part of confirming that your redundancy setup really works.

Reply on news.ycombinator.com