4 ms·

Another alternative is just bypass the Deb repo's altogether and install from source, but do so using the awesome Debian Alternatives tool [1] so as not to drop

Another alternative is just bypass the Deb repo's altogether and install from source, but do so using the awesome Debian Alternatives tool [1] so as not to drop a bunch of unmanaged files into /usr/bin, /usr/local/bin, etc. Takes some setup work, but very powerful and useful after you get it working. Example scripts: https://github.com/byrongibson/scripts/tree/master/install/haskell https://github.com/byrongibson/scripts/tree/master/install/h... https://github.com/byrongibson/scripts/tree/master/install/java https://github.com/byrongibson/scripts/tree/master/install/j... https://github.com/byrongibson/scripts/tree/master/install/scala https://github.com/byrongibson/scripts/tree/master/install/s... Can do similarly with any other package. Download and compile the source to --prefix=/opt/name/version, look at the /opt structure (it will mirror /usr/bin, /usr/local/bin/, /usr/share/man) and script the update-alternatives command correspondingly. Tons of benefits, among them being better post-install startup control, but also you can install multiple versions side-by-side and swap among with a single command. Upgrade painlessly, rollback if the new version breaks things, all very easily. Reminiscent of Gobo Linux [2] but still a Debian. [1]:https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives [2]:https://en.wikipedia.org/wiki/GoboLinux https://en.wikipedia.org/wiki/GoboLinux

ars 12y ago
If you do that then you lose the automatic package updates, for example for a security update. And that's one of the best parts of Debian.
- atoponce 12y ago
  Installing packages from source is fine, but then you have to maintain all security updates and patches from upstream, and you need full control over where all the files are populated on your filesystem. This is a lot of administration overhead. It "works", but it's also work. I rarely install software outside of the APT system, for this very reason.
  - SkyMarshal 12y ago
    Yeah, if apt has the versions you need it's definitely first choice. But for a lot of things it lags too much, and that's where this is useful.
- SkyMarshal 12y ago
  True, but for your primary tech stack you should be on top of that anyway, and the benefit is you can install the full updated version beside the old version, swap over to the updated version with a command, test your app, and if there are any regressions, roll back to the old version with a command. Anything not part of your primary stack, sure use the repo.
cdjk 12y ago
I've used stow to manage installs under /use/local before, which seems like a slightly easier approach. It does something similar but manages the install as a series of symlinks from /usr/local/bin to /usr/local/stow/<packagename>/bin. It's pretty easy to setup and works the same on any distro.
- SkyMarshal 12y ago
  I tried stow a while back too but there was something I didn't like about it, but can't remember. It might have been that stow only supports a single version of each package or something, less flexibility in putting version no in the paths, maybe?

ars 12y ago

If you do that then you lose the automatic package updates, for example for a security update. And that's one of the best parts of Debian.

atoponce 12y ago
Installing packages from source is fine, but then you have to maintain all security updates and patches from upstream, and you need full control over where all the files are populated on your filesystem. This is a lot of administration overhead. It "works", but it's also work. I rarely install software outside of the APT system, for this very reason.
- SkyMarshal 12y ago
  Yeah, if apt has the versions you need it's definitely first choice. But for a lot of things it lags too much, and that's where this is useful.
SkyMarshal 12y ago
True, but for your primary tech stack you should be on top of that anyway, and the benefit is you can install the full updated version beside the old version, swap over to the updated version with a command, test your app, and if there are any regressions, roll back to the old version with a command. Anything not part of your primary stack, sure use the repo.

cdjk 12y ago

I've used stow to manage installs under /use/local before, which seems like a slightly easier approach. It does something similar but manages the install as a series of symlinks from /usr/local/bin to /usr/local/stow/<packagename>/bin. It's pretty easy to setup and works the same on any distro.

SkyMarshal 12y ago
I tried stow a while back too but there was something I didn't like about it, but can't remember. It might have been that stow only supports a single version of each package or something, less flexibility in putting version no in the paths, maybe?