[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: concurrent installation of different pkg versions



(I am Cc: debian-science, since this is probably specific to science)

On 30.04.2014 03:45, Thomas Goirand wrote:
> This is the exact same thing that happens with .so libraries, and
> this should happen *only* when there's an API change (why would you
> want to keep an older version otherwise?).

Because the *behaviour* changes. As an example: Consider that someone
does a spectral analysis and needs the spectra in a certain binning. For
this, he uses a some (debianized :-) ) software. However he finds that
the resulting spectra are somehow shifted from what he expected.

In this case, many scientists I know would *not* go by and debug the
rebinning software. They would take the software as a black box and just
investigate how to shift the spectrum back to its expected position.
This is then tested on known data, and finally used for the analysis.
And if he wrote his own piece of software, this correction goes into the
source (and even may be packaged on Debian).

If now the rebinning software is updated and the bug is corrected, the
analysis of these scientist will not anymore be correct. Therefore, many
scientists fear updates of their operating systems, and especially of
the scientific libraries they use.

I don't think that this behaviour is really correct (in a scientific
sense), and I am not sure whether Debian should support this -- but the
acceptance by scientists raises if they can (co-)install certain
versions, even if they are API compatible. CERN did this (at least) with
their own CERNLIB, which was installed (far before FHS) on
/cern/<version> with links

/cern/pro
/cern/new
/cern/old

to the current, the next (to be tested) and the previous release. ESO
pipelines (cpl-plugin-* on Debian) also have the version number in their
installation path.

The main reason is that an average scientist (PhD student which a
short-term contract) just does not have the experience nor the resources
to investigate the software he depends on to actually find the bug (or
even to find out which software is responsible).

Best regards

Ole


Reply to: