3 ms·

Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. It's worth

Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. It's worth noting that Debian can be made to support PPAs as well, but all this is native to Ubuntu. I can't deny the Ubuntu community is extensive and there are in-depth articles covering setup of just about anything on Ubuntu. Fortunately, owing to the Debian basis, it's fairly easy to convert the same tutorials to run on Debian.

philamonster 9y ago
https://www.dotdeb.org/ https://www.dotdeb.org/ usually handles needs for more common late release packages in Debian.
ubernostrum 9y ago
The main issue is trying to use the distro packages for dependencies of the things you'll actually use the server for. Over in the Python world I'd be perfectly happy to use Debian. I'd just use it only to provide an operating system; then I'd compile the version of Python I want, and use virtualenvs and pip for managing the actual application code and dependencies.
- aoeusnth1 9y ago
  Agreed. Package managers are OK for a lay user, but if you actually want to run code in production you're better off with a reproducible and isolated environment you created yourself.
stephenr 9y ago
Updated php builds are available from https://deb.sury.org https://deb.sury.org - they're available for both Debian and Ubuntu. The operator of that repo is also a Debian maintainer, so they follow the same practices. For nodejs you're better off using a vendor like nodesource regardless of your distro.
snuxoll 9y ago
> Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. I really wish other distributions would steal the idea of software collections from Red Hat. Having newer runtimes and database engines available out-of-band is a great idea, especially considering SCL packages live in an isolated root and won't interfere with the base system.
- stephenr 9y ago
  > out-of-band I'm not sure I know what you mean by out-of-band ? Installed via something other than rpms? Installed from non-official rpm repos? It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. The PHP packages for 5.6 onwards on Debian are built such that they can be installed side-by-side. Building on this basis, dotdeb.org and deb.sury.org have offered back ported versions of PHP built for stable, oldstable etc. From Buster (testing) it appears there will be multiple versions in the main repo (Buster currently has 7.0 and 7.1 packages)
  - snuxoll 9y ago
    > Installed via something other than rpms? Installed from non-official rpm repos? Software Collections aren't part of the main repositories, they're an optional repository that can be enabled and have different guidelines for updates and new packages than the core repositories do. They're effectively divorced from the normal scrutiny and stability concerns that every package in the core RHEL repos has to go through, newer packages get pushed out faster as a result. > It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. That's precisely what Software Collections do, they go one step further and isolate each runtime and require it be manually enabled for use (rhscl enable python3.5 `command goes here`) - there's no potential for the core system to be affected and you can layer different collections together if needed.
    - stephenr 9y ago
      The first part sounds like it's solved by a combination of the $release-backports repo, and vendor repos. The second part sounds interesting - sounds vaguely like using a chroot, so the 'target' just knows to run python, not which specific version its going to run, for instance?

philamonster 9y ago

https://www.dotdeb.org/ https://www.dotdeb.org/ usually handles needs for more common late release packages in Debian.

ubernostrum 9y ago

The main issue is trying to use the distro packages for dependencies of the things you'll actually use the server for. Over in the Python world I'd be perfectly happy to use Debian. I'd just use it only to provide an operating system; then I'd compile the version of Python I want, and use virtualenvs and pip for managing the actual application code and dependencies.

aoeusnth1 9y ago
Agreed. Package managers are OK for a lay user, but if you actually want to run code in production you're better off with a reproducible and isolated environment you created yourself.

stephenr 9y ago

Updated php builds are available from https://deb.sury.org https://deb.sury.org - they're available for both Debian and Ubuntu. The operator of that repo is also a Debian maintainer, so they follow the same practices. For nodejs you're better off using a vendor like nodesource regardless of your distro.

snuxoll 9y ago

> Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. I really wish other distributions would steal the idea of software collections from Red Hat. Having newer runtimes and database engines available out-of-band is a great idea, especially considering SCL packages live in an isolated root and won't interfere with the base system.

stephenr 9y ago
> out-of-band I'm not sure I know what you mean by out-of-band ? Installed via something other than rpms? Installed from non-official rpm repos? It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. The PHP packages for 5.6 onwards on Debian are built such that they can be installed side-by-side. Building on this basis, dotdeb.org and deb.sury.org have offered back ported versions of PHP built for stable, oldstable etc. From Buster (testing) it appears there will be multiple versions in the main repo (Buster currently has 7.0 and 7.1 packages)
- snuxoll 9y ago
  > Installed via something other than rpms? Installed from non-official rpm repos? Software Collections aren't part of the main repositories, they're an optional repository that can be enabled and have different guidelines for updates and new packages than the core repositories do. They're effectively divorced from the normal scrutiny and stability concerns that every package in the core RHEL repos has to go through, newer packages get pushed out faster as a result. > It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. That's precisely what Software Collections do, they go one step further and isolate each runtime and require it be manually enabled for use (rhscl enable python3.5 `command goes here`) - there's no potential for the core system to be affected and you can layer different collections together if needed.
  - stephenr 9y ago
    The first part sounds like it's solved by a combination of the $release-backports repo, and vendor repos. The second part sounds interesting - sounds vaguely like using a chroot, so the 'target' just knows to run python, not which specific version its going to run, for instance?