4 ms·

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)

by yebyen 11y ago

oblio 11y ago
https://help.ubuntu.com/community/PinningHowto https://help.ubuntu.com/community/PinningHowto My guess is that apt pinning/holding predates Gemfile.lock by quite a few years :)
- yebyen 11y ago
  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.
  - icebraining 11y ago
    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.
    - yebyen 11y ago
      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.
      - icebraining 11y ago
        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.
icebraining 11y ago
Usually configuration management tools like Ansible are used.
felipellrocha 11y ago
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...
sciurus 11y ago
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/ http://www.aptly.info/ which simplify the process of locking packages in environments.

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)

by yebyen 11y ago

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)

oblio 11y ago

https://help.ubuntu.com/community/PinningHowto https://help.ubuntu.com/community/PinningHowto My guess is that apt pinning/holding predates Gemfile.lock by quite a few years :)

yebyen 11y ago
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.
- icebraining 11y ago
  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.
  - yebyen 11y ago
    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.
    - icebraining 11y ago
      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.

icebraining 11y ago

Usually configuration management tools like Ansible are used.

felipellrocha 11y ago

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...

sciurus 11y ago

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/ http://www.aptly.info/ which simplify the process of locking packages in environments.