Comment by SkyMarshal | Hacker News Reader

Comment by SkyMarshal | Hacker News Reader

Parent Full thread

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

https://github.com/byrongibson/scripts/tree/master/install/j...

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

[2]:https://en.wikipedia.org/wiki/GoboLinux

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.

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.

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.

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.

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.

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?

Reply on news.ycombinator.com