[Neurodebian-users] keep multiple neurodebian software versions

[marco tettamanti]

Dear Michael

On 02/22/2011 04:19 PM, Michael Hanke wrote:
> Hi,
>
> On Tue, Feb 22, 2011 at 03:46:48PM +0100, marco tettamanti wrote:
>> Basically, there are softwares (e.g. mricron/dcm2nii or fsl), for
>> which I very much want to use the same version to analyze a specific
>> data set, in order to be sure to keep all relevant processing
>> parameters constant across the experiment. Under some circumstances,
>> this may require having multiple software versions installed, in
>> order to benefit from software upgrades for newer experiments but
>> still be able to use older versions to analyze, modify or review
>> older experiments.
>
> You are pointing to an important issue. We do support co-installation of
> FSL, but not for most others. The primary reason is that virtually no
> projects actually maintain old versions of their software. You need to
> upgrade to get the bugfixes. We have no resource to do the bugfix
> backports ourselves. And you really want the bugfixes to make sure you
> results are not an artifact of a software bug -- where it would be good
> thing if they go away with an upgrade ;-)
>
> But the actual issue is more global than it looks like. Even if you
> kept your old version of FSL around it could still change its behavior
> over time. The reason is that pretty much all software relies on
> computational and other 3rd-party libraries. Those libs are installed on
> the system and change independently from the "frontend" software itself.
> Consequently, just keeping FSL's version constant doesn't help you much.
>
> One solution is to snapshot your whole analysis environment and archive
> it together with the data of any study. You can easily do that with
> Virtual Machines (like ours), or chroots if that is enough. The
> advantages of VMs are that you can take them out some years later, boot
> them up and run a re-analysis in exactly the same environment -- even
> after your original machine died, or you moved to another lab and don't
> even have access to it anymore.
>
> Given that it is very cheap to snapshot the whole system and very time
> consuming to maintain co-installable software with countless versions and
> dependencies we generally favor to former for practical purposes.
>
> Does that make sense?

Yes, absolutely! I never really thought about the influences of 3rd-party 
libraries and the solution you suggest is great.

This also brings me to another question: it is hard for me to tell just from apt 
whether an available package update represents a major software upgrade (e.g. 
new functions implemented), a set of bug fixes released by the software's 
developers, or, in the case of neurodebian, a set of bug fixes related to debian 
released by the software's maintainer.
Do you follow any package naming policies that allows one to distinguish from 
these different upgrade types?

Best,
Marco

-- 
Marco Tettamanti, Ph.D.
San Raffaele Scientific Institute
Via Olgettina 58
I-20132 Milano, Italy
Tel. ++39-02-26434888
Fax ++39-02-26434892
Email: tettamanti.marco at hsr.it

-----------------------------------------------------------------------------------
SOSTIENI ANCHE TU LA RICERCA DEL SAN RAFFAELE.
NON C'E' CURA SENZA RICERCA.
Per donazioni: ccp 42437681 intestato a Fondazione Arete' Onlus del San Raffaele.
Per informazioni: tel. 02.2643.4461 - www.sanraffaele.org