Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: