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

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

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?