5 ms·

This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring)

This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring) required 2.2 because RHEL3 is still supported (in production phase 3, see http://www.redhat.com/security/updates/errata/ http://www.redhat.com/security/updates/errata/) until Oct 31, 2010. Python is easy to install, but it's a lot to ask of users when they just want to get your software up and running. Note that RHEL4 sees end of life Feb 29, 2012 and RHEL5 not until Mar 31, 2014. So Python-2.4 support will have to live for a very long time. I hate this, but don't see a decent alternative. Many of our users are building in batch environments of varying ages and just want to get their science done. Shell/bash is not very portable, it would be painful to write all the configuration in C (and confusing because people would need to both native compilers and cross-compilers).

igravious 16y ago
This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite language and especially the scripting ones and virtual machines one will have there own repositories that are _not_ linked into the systems way of doing things. So at the system level we have RPM and Yum and Ports and Portage and Macports and Fink and Homebrew and AptGet and Conary and yada yada yada but at the language level we have (deep breath) Perl and CPAN, Ruby and GEMS, Python and EGGS, and Emacs and ? and Java and Eclipse plugins and on and on. I would switch IN AN INSTANT to the distro that integrated all this so that I would only need to go to ONE place to upgrade system packages and language packages. Honestly if nobody does it one of these years I might even be forced to do it myself and make mega $ € ¥. Hope this makes sense to somebody somewhere. :)
- jedbrown 16y ago
  have there own repositories that are _not_ linked into the systems way of doing things One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this. I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when the distro upgrades it's copy (or switch to the next 6-month release with Ubuntu and similar).
  - igravious 16y ago
    Indeed. This is why I would never install Eclipse from synaptic on Ubuntu because the Ubuntu schedules and Eclipse schedules differed. And perhaps they wouldn't coincide anyway even if they synchronised temporally. Which means that someone somewhere is wasting there time packaging Eclipse for Debian/Ubuntu.
  - regularfry 16y ago
    I've no direct experience of Arch, but the traditional problem with integrating rubygems is that it expects to be able to install more than one version side-by-side. That's alien enough from the packge management point of view, but when it's de facto idiomatic to specify required versions and manipulate the load path at runtime, it makes integrating with a distro downright fiddly.

igravious 16y ago

This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite language and especially the scripting ones and virtual machines one will have there own repositories that are _not_ linked into the systems way of doing things. So at the system level we have RPM and Yum and Ports and Portage and Macports and Fink and Homebrew and AptGet and Conary and yada yada yada but at the language level we have (deep breath) Perl and CPAN, Ruby and GEMS, Python and EGGS, and Emacs and ? and Java and Eclipse plugins and on and on. I would switch IN AN INSTANT to the distro that integrated all this so that I would only need to go to ONE place to upgrade system packages and language packages. Honestly if nobody does it one of these years I might even be forced to do it myself and make mega $ € ¥. Hope this makes sense to somebody somewhere. :)

jedbrown 16y ago
have there own repositories that are _not_ linked into the systems way of doing things One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this. I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when the distro upgrades it's copy (or switch to the next 6-month release with Ubuntu and similar).
- igravious 16y ago
  Indeed. This is why I would never install Eclipse from synaptic on Ubuntu because the Ubuntu schedules and Eclipse schedules differed. And perhaps they wouldn't coincide anyway even if they synchronised temporally. Which means that someone somewhere is wasting there time packaging Eclipse for Debian/Ubuntu.
- regularfry 16y ago
  I've no direct experience of Arch, but the traditional problem with integrating rubygems is that it expects to be able to install more than one version side-by-side. That's alien enough from the packge management point of view, but when it's de facto idiomatic to specify required versions and manipulate the load path at runtime, it makes integrating with a distro downright fiddly.