Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 30/04/14 03:45, Thomas Goirand wrote:
> On 04/26/2014 01:39 AM, Daniel Pocock wrote:
>>
>> With all the talk about removing jquery from source packages, one thing
>> that does arise is the question of how to support different jquery versions.
>>
>> This is not just a JavaScript issue though.  Maybe we can have
>>
>>   libjs-jquery-1.7
>>   libjs-jquery-1.10
> There's nothing that prevents us from manually deciding to have
> different versions installed at once: this is a packaging decision. We
> could have for example:
>
> >From package libjs-jquery-1.7:
> /usr/share/javascript/jquery/1.7
>
> >From package libjs-jquery-1.10:
> /usr/share/javascript/jquery/1.10
>
> 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?).
>
> I strongly believe that this should be avoided as much as possible (for
> example with good communication with upstream so that they understand
> the needs of distributions), though there's some cases where probably
> it's impossible. I wouldn't like if we were generalizing the practice,
> but would understand and feel reasonable if we had a few cases of it,
> for example let's say 2  jquery versions at once max on a give system.

This is still something that keeps coming up for me.  I gave jQuery as
an example because it is so common but the more specific cases I am
thinking about involve applications that share a database and must run
an application version that matches the schema version.

I'm currently thinking that the postbooks packages will start to be
named postbooks-4.7, postbooks-4.8 etc and will install concurrently.

In a single instance of PostgreSQL, a user may have different schemas
for different versions of postbooks.  This type of scenario is
particularly common in support and development environments for such
software or for people who are testing a new version.

>From what I can see, this already happens for:
- shared libraries (ABI version in package name)
- PostgreSQL servers (e.g. the package name postgresql-9.4 from jessie
installs concurrently with postgresql-9.1)
- gcc (e.g. gcc-4.6, gcc-4.7 installed concurrently)

I made a search for documentation about this package naming/versioning
strategy and while there are details for shared libraries I couldn't
find anything about the more general case.  Can anybody make any more
specific comment about this or suggest other documents that cover this
topic?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546b510c.9090...@pocock.pro

Re: concurrent installation of different pkg versions

[Wouter Verhelst]

Hi Charles,

Op zaterdag 26 april 2014 14:29:44 schreef Charles Plessy:
> Le Fri, Apr 25, 2014 at 10:11:58PM -0700, Steve Langasek a écrit :
> > On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
> > > Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a écrit :
> > > > On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> > > > > a generalized approach is needed.
> > > > 
> > > > Multiple versions of a package seems undesirable to me, for the 
same
> > > > reasons as static libraries and embedded code copies are 
undesirable.
> > > 
> > > Hi Paul and everybody,
> > > 
> > > it would be a great advantage for Debian over the other 
distributions to
> > > have the capacity to install multiple versions concurrently.
> > 
> > No, no it wouldn't.
> > 
> > This is how rpm handles library packages.  It's a horror show.
> 
> Hi Steve,
> 
> we have been fighting bitterly over the years, we have different points of
> view, and it does not seem like we will be thiking along the same lines
> anytime soon.
> 
> When you post on debian-devel or other lists and I disagree, I try to
> refrain myself from juping on the keyboard and to instead give time to
> others to express their disagreement.  If nobody answers, I also take it 
as
> a sign that I probably should not answer as well.
> 
> Could I ask you to do the same for me ?

While I subscribe to your request for Steve to be considerate (heck, I 
wouldn't have caused GR 2014-002 if I didn't), I don't think asking him not 
to reply to you is a reasonable request.

Steve is a valued technical contributor who through more than a decade of 
experience has valuable insights to add to many parts of Debian. Asking 
him to keep that technical advise to him for personal reasons seems like a 
wrong thing to do.

The above-quoted mail could maybe use a bit more explanation as to why 
Steve thinks of your suggestion as a bad idea. However, that doesn't make 
him wrong, nor should it imply that he should have refrained from sending 
it.

Thanks,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: concurrent installation of different pkg versions

[Alastair McKinstry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

modules.sourceforge.net is in debian as "environment-modules"

regards
Alastair

On 30/04/2014 18:46, Steve Moss wrote:
> Check out modules and lmod for this:
>
> http://modules.sourceforge.net
> https://github.com/TACC/Lmod
>
> Cheers,
>
> Steve
>
> --
> Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
> A decent provision for the poor is the true test of civilization.
> ~Samuel Johnson, Boswell: Life of Johnson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTYUMVAAoJEN9LdrZRJ3QsfoEQAJBA3RL/20o9DNeu2Xu7F7N0
Z1I9rxiX57FEWeXN0pfr6h99tQiQRCMA6omuGeklJ5ICqQgj2dSnGlYWV7ZG6z47
h3X+RCGyyjH3l1k3F5pbI7570XC72oJDTf4Z68z09cYftTyyNWia0VI7Eu8K4bHr
3MaMkmoXkj/6C6ovPvFs3yXhmDP0aEC2Zdab/85zhNdDSBju/BhlfBeHqkgOdjEt
l6ZK5N/xqXo8klIMujclUL8VXtli7H06e0BtJfXS9MUxlJfDpNP4I7n9sHC+LX0G
MFmdDz/8uTxuwBOmWFXBWYtLBBv7yhivrr/P9Da//iR4MxqBPP5ZKbe3ZS+JHA0k
xHX5F4WIiyxFDI45myXSrpsX9LBs7ycgfAH8maA7QQzuOyh38kgj+79tHXsXDJEU
Q7bXZYFySiYTrG41wkmPW8/1p5G88CZrPywlbWcd/QbricraDBZ/4Hgb2cTtBdII
RRGPX7q/36CTPhUzKFg+WjHhLURxq9h/gUa8cpyWC/Fvxl0vlcguxBAMPKPiuSZN
eOMOzCQo2jCjqPJTOXpNTlcK9PGDCeHbqRMbduPZZxRLkXG13aS+unXQcUOfBjlG
mIIAzo56OphqSy9yBMaJ87dGkJJPO/+qevAXKeOY64R2/+jcOxwGOxzxK/Z8A+z9
a70GYM1Dpl9lZzW/c1gc
=XQLt
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53614315.6070...@debian.org

Re: concurrent installation of different pkg versions

[Steve Moss]

Check out modules and lmod for this:

http://modules.sourceforge.net
https://github.com/TACC/Lmod

Cheers,

Steve

Re: concurrent installation of different pkg versions

[Ole Streicher]

(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/ 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5360a5da.60...@liska.ath.cx

Re: concurrent installation of different pkg versions

[Thomas Goirand]

On 04/26/2014 01:39 AM, Daniel Pocock wrote:
> 
> 
> With all the talk about removing jquery from source packages, one thing
> that does arise is the question of how to support different jquery versions.
> 
> This is not just a JavaScript issue though.  Maybe we can have
> 
>   libjs-jquery-1.7
>   libjs-jquery-1.10

There's nothing that prevents us from manually deciding to have
different versions installed at once: this is a packaging decision. We
could have for example:

>From package libjs-jquery-1.7:
/usr/share/javascript/jquery/1.7

>From package libjs-jquery-1.10:
/usr/share/javascript/jquery/1.10

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

I strongly believe that this should be avoided as much as possible (for
example with good communication with upstream so that they understand
the needs of distributions), though there's some cases where probably
it's impossible. I wouldn't like if we were generalizing the practice,
but would understand and feel reasonable if we had a few cases of it,
for example let's say 2  jquery versions at once max on a give system.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536055d2.2040...@debian.org

Re: concurrent installation of different pkg versions

[Adam Sampson]

Jeremy Stanley  writes:

> An academic librarian friend of mine has been working with the various
> departments at his institution to start producing and archiving
> virtual machine images preconfigured for running the software used to
> generate results corresponding to various publications,

I'm not sure if it's the same project, but there's also this effort that
some researchers local to me are involved in:

  http://recomputation.org/

-- 
Adam Sampson  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/y2aioprk7zx@cartman.at.offog.org

Re: concurrent installation of different pkg versions

[Steve Langasek]

On Sat, Apr 26, 2014 at 06:21:33AM -0700, Russ Allbery wrote:
> Steve Langasek  writes:
> > On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:

> >> it would be a great advantage for Debian over the other distributions
> >> to have the capacity to install multiple versions concurrently.

> > No, no it wouldn't.

> > This is how rpm handles library packages.  It's a horror show.

> All of our research computing systems run Red Hat (or CentOS) because
> that's where the people who care about concurrent installation of
> different versions have gone, since no one in the Debian and Ubuntu world
> with influence seems to care about their problems.

I'm not saying that this isn't a problem that should be addressed.  I'm
saying that trying to treat this as installation of multiple versions of the
same package is a terrible design.  We of course want Debian to meet the
needs of all our (potential) users, but this shouldn't come at the expense
of the integrity of our package system.

We already support coinstallability of shared libraries and interpreters,
/under different package names/, and this works reliably.  It also requires
a good deal of care to get right, to ensure that interfaces are properly
versioned where they need to be.  There's no reason that this can't be
extended to other kinds of packages, but it's not something that will ever
work sanely without some per-package attention; and even then, chances are
that we're only going to provide security support for one version of the
package in a given release.

And if the users aren't going to get security support, why do they care
about the software being provided via the distro?  They can do a local
install just as well, or use unofficial packages in a container, for the
same result.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: concurrent installation of different pkg versions

[Jeremy Stanley]

On 2014-04-27 20:50:38 -0700 (-0700), Russ Allbery wrote:
[...]
> Containers would be a better environment, but you have to make
> them very, very simple to set up.
[...]

An academic librarian friend of mine has been working with the
various departments at his institution to start producing and
archiving virtual machine images preconfigured for running the
software used to generate results corresponding to various
publications, so that they can later be cloned, booted and results
reverified in the original environments and conditions. Admittedly
this means lots of additional storage, but it does offer an easy way
out of that particular dilemma (assuming the bitrot isn't so bad
that nobody can find virtualization software capable of booting them
successfully in the future).
-- 
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140429225903.gm11...@yuggoth.org

Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 28/04/14 21:16, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-04-28 20:10:09)
>> On 28/04/14 18:59, Gunnar Wolf wrote:
>>> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
> a generalized approach is needed.
 Multiple versions of a package seems undesirable to me, for the 
 same reasons as static libraries and embedded code copies are 
 undesirable.
>>> [...] It makes sense for a programmer [...]
>>> But supporting this as a whole is a mess.
>> I'm not suggesting that this is a practice that should be encouraged 
>> nor given the same level of security support in every case.
>>
>> However, there are cases (e.g. hundreds of packages containing jquery) 
>> where it becomes the lesser evil: instead of having hundreds of copies 
>> of non-standard JavaScript dependencies, we end up with maybe 3 or 4 
>> supported versions of each important library.
> What level of support _are_ you talking about - at all?
>
> I fail to understand: How are packages magically "supported" by it being 
> possible to co-install both the version maintained ordinarily and older 
> instances of same package no longer maintained but e.g. fetched from 
> snapshot.d.o?
>
> If you imply support from the security team for snapshot.d.o then I find 
> it quite important to state explicitly what you have in mind.
>
> If you imply support from the package maintainer, then I find it more 
> sensible to simply maintain as separate packages for each "branch" that 
> the maintainer deem sensible to support - as we are doing with a range 
> of packages.
>
> If you don't really mean "supported", just "possible" then there are 
> several ways a sysadmin can either maintain a separate virtualized full 
> Debian installations or a custom versions of code (possibly simplest 
> being to pile stuff up below /usr/local or withing the project needing 
> it).

Perhaps the support burden for legacy versions should be taken up by
those people packaging things that depend on the legacy versions.

They would then have to weigh up the benefits of getting upstream to
work with newer jquery or supporting a legacy jquery package.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535f6f74.6080...@pocock.pro

Re: concurrent installation of different pkg versions

[Jonas Smedegaard]

Quoting Daniel Pocock (2014-04-28 20:10:09)
> On 28/04/14 18:59, Gunnar Wolf wrote:
> > Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
> >>> a generalized approach is needed.
> >>
> >> Multiple versions of a package seems undesirable to me, for the 
> >> same reasons as static libraries and embedded code copies are 
> >> undesirable.
> > [...] It makes sense for a programmer [...]
> > But supporting this as a whole is a mess.

> I'm not suggesting that this is a practice that should be encouraged 
> nor given the same level of security support in every case.
> 
> However, there are cases (e.g. hundreds of packages containing jquery) 
> where it becomes the lesser evil: instead of having hundreds of copies 
> of non-standard JavaScript dependencies, we end up with maybe 3 or 4 
> supported versions of each important library.

What level of support _are_ you talking about - at all?

I fail to understand: How are packages magically "supported" by it being 
possible to co-install both the version maintained ordinarily and older 
instances of same package no longer maintained but e.g. fetched from 
snapshot.d.o?

If you imply support from the security team for snapshot.d.o then I find 
it quite important to state explicitly what you have in mind.

If you imply support from the package maintainer, then I find it more 
sensible to simply maintain as separate packages for each "branch" that 
the maintainer deem sensible to support - as we are doing with a range 
of packages.

If you don't really mean "supported", just "possible" then there are 
several ways a sysadmin can either maintain a separate virtualized full 
Debian installations or a custom versions of code (possibly simplest 
being to pile stuff up below /usr/local or withing the project needing 
it).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 28/04/14 18:59, Gunnar Wolf wrote:
> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
>>> a generalized approach is needed.
>>
>> Multiple versions of a package seems undesirable to me, for the same
>> reasons as static libraries and embedded code copies are undesirable.
>>
>> Systems that do this already exist though:
>>
>> https://nixos.org/
>> http://www.gobolinux.org/
> 
> I have long lamented that's the direction the Ruby community took with
> Gems¹.
> 
> Gems support different versions installed on a system, as well as
> depending on specific versions. It makes sense for a programmer
> keeping track of different systems with changing APIs — Not having
> coinstalability means they'd have to patch all of their systems every
> time an API changes. Which happens on a daily basis in Ruby-land.
> 
> But supporting this as a whole is a mess. We try to make sure our
> system is a coherent unit, and that security and reliabilty fixes are
> applied to all or our packages (yes, that's the reason why I spent
> most of my Debian time in the past two weeks dealing with a single
> issue in Drupal7: Waiting for the right times to upload the fixes for
> stable / unstable / testing / bpo70 / bpo60).
> 
> Were we to support coinstallable multiple versions, we would have a
> much harder time supporting security.
> 
> For some cases (i.e. Daniel's suggestion of JQuery), the installed
> base and the incompatibilities between versions mean it could very
> well make sense. Right now, we *do* ship different JQuery versions,
> because several of our packages are incompatible with the systemwide
> one... But that's a bug, not a feature.
> 

nvm for Node.js is a bit like that too

I'm not suggesting that this is a practice that should be encouraged nor
given the same level of security support in every case.

However, there are cases (e.g. hundreds of packages containing jquery)
where it becomes the lesser evil: instead of having hundreds of copies
of non-standard JavaScript dependencies, we end up with maybe 3 or 4
supported versions of each important library.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e9981.8040...@pocock.pro

Re: concurrent installation of different pkg versions

[Gunnar Wolf]

Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
> > a generalized approach is needed.
> 
> Multiple versions of a package seems undesirable to me, for the same
> reasons as static libraries and embedded code copies are undesirable.
> 
> Systems that do this already exist though:
> 
> https://nixos.org/
> http://www.gobolinux.org/

I have long lamented that's the direction the Ruby community took with
Gems¹.

Gems support different versions installed on a system, as well as
depending on specific versions. It makes sense for a programmer
keeping track of different systems with changing APIs — Not having
coinstalability means they'd have to patch all of their systems every
time an API changes. Which happens on a daily basis in Ruby-land.

But supporting this as a whole is a mess. We try to make sure our
system is a coherent unit, and that security and reliabilty fixes are
applied to all or our packages (yes, that's the reason why I spent
most of my Debian time in the past two weeks dealing with a single
issue in Drupal7: Waiting for the right times to upload the fixes for
stable / unstable / testing / bpo70 / bpo60).

Were we to support coinstallable multiple versions, we would have a
much harder time supporting security.

For some cases (i.e. Daniel's suggestion of JQuery), the installed
base and the incompatibilities between versions mean it could very
well make sense. Right now, we *do* ship different JQuery versions,
because several of our packages are incompatible with the systemwide
one... But that's a bug, not a feature.

¹ http://www.rubygems.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140428165929.gg44...@gwolf.org

Re: concurrent installation of different pkg versions

[Tollef Fog Heen]

]] Don Armstrong 

> On Sat, 26 Apr 2014, Russ Allbery wrote:
> > And simultaneous installation of multiple versions of packages is
> > simply a requirement for many research computing scenarios, usually
> > because there's a lot of bespoke scientific code that accomplishes
> > some specific goal but was not written to the standards one would
> > expect from professional programmers, and therefore doesn't easily
> > work with newer versions of libraries.
> 
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.

You might also have success by using omnibus,
https://github.com/opscode/omnibus-ruby

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ha5drcss@xoog.err.no

Re: concurrent installation of different pkg versions

[Josselin Mouette]

Le dimanche 27 avril 2014 à 17:16 -0700, Don Armstrong a écrit :
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.

You don’t have to go that far. We’re having good results with specific
deb packages installing the application with all non-system libraries
in /opt/package/version.

> The quality of almost every single piece of scientific code I've ever
> worked with is so appalling that I'm always amazed when any of it
> produces any useful results, ever. And lets not even talk about whether
> the results it produces are accurate or reproducible...

Amen to that.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1398675254.7402.2.ca...@kagura.malsain.org

Re: concurrent installation of different pkg versions

[Andreas Tille]

On Sun, Apr 27, 2014 at 08:50:38PM -0700, Russ Allbery wrote:
> Containers would be a better environment, but you have to make them very,
> very simple to set up.

You mean like something imaginary command like

  create_my_vm --

creating a virtual machine and installs  with the specified
version from snapshots.debian.org and all its dependencies available
at the time when this package version was uploaded?
 
> > The quality of almost every single piece of scientific code I've ever
> > worked with is so appalling that I'm always amazed when any of it
> > produces any useful results, ever. And lets not even talk about whether
> > the results it produces are accurate or reproducible...
> 
> Well, yes.  It's a ton of code written by people who aren't really
> programmers and who have lots of other things they care more about than
> becoming better programmers.

+1

Kind regards

  Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140428062925.gc8...@an3as.eu

Re: concurrent installation of different pkg versions

[Russ Allbery]

Don Armstrong  writes:
> On Sat, 26 Apr 2014, Russ Allbery wrote:

>> And simultaneous installation of multiple versions of packages is
>> simply a requirement for many research computing scenarios, usually
>> because there's a lot of bespoke scientific code that accomplishes some
>> specific goal but was not written to the standards one would expect
>> from professional programmers, and therefore doesn't easily work with
>> newer versions of libraries.

> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.

Yeah, usually what happens in practice is that a complex set of
environment variables and shell scripts are used to let people set up
their local environment to pick up a particular version of a package, but
the amount of combinatoric complexity that involves is rather high.
Containers would be a better environment, but you have to make them very,
very simple to set up.

> The quality of almost every single piece of scientific code I've ever
> worked with is so appalling that I'm always amazed when any of it
> produces any useful results, ever. And lets not even talk about whether
> the results it produces are accurate or reproducible...

Well, yes.  It's a ton of code written by people who aren't really
programmers and who have lots of other things they care more about than
becoming better programmers.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871twidsdt@windlord.stanford.edu

Re: concurrent installation of different pkg versions

[Matthias Klumpp]

2014-04-28 2:16 GMT+02:00 Don Armstrong :
> On Sat, 26 Apr 2014, Russ Allbery wrote:
>> And simultaneous installation of multiple versions of packages is
>> simply a requirement for many research computing scenarios, usually
>> because there's a lot of bespoke scientific code that accomplishes
>> some specific goal but was not written to the standards one would
>> expect from professional programmers, and therefore doesn't easily
>> work with newer versions of libraries.
>
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.
>
> The quality of almost every single piece of scientific code I've ever
> worked with is so appalling that I'm always amazed when any of it
> produces any useful results, ever. And lets not even talk about whether
> the results it produces are accurate or reproducible...
I absolutely agree with both statements. And I would love to print out
the last quote in poster-size and place it in our lab :-)
However, there is some pretty good scientific software around, and
there are labs where programmers and other researchers work together
well to produce great software and great results.
But anyway, to give some input: We're exploring containerization here
for exactly that purpose (running old software versions in a defined
environment with less overhead).
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caknhny8_njwa7psm_lt-qi2leebkkx-pfx5p4cut8gt4ya+...@mail.gmail.com

Re: concurrent installation of different pkg versions

[Don Armstrong]

On Sat, 26 Apr 2014, Russ Allbery wrote:
> And simultaneous installation of multiple versions of packages is
> simply a requirement for many research computing scenarios, usually
> because there's a lot of bespoke scientific code that accomplishes
> some specific goal but was not written to the standards one would
> expect from professional programmers, and therefore doesn't easily
> work with newer versions of libraries.

The right way to handle this for research computing scenarios is to
deploy virtual machines with specific versions otherwise you're
constantly battling with trying to make sure that you're actually using
the version that you think you're using.

The quality of almost every single piece of scientific code I've ever
worked with is so appalling that I'm always amazed when any of it
produces any useful results, ever. And lets not even talk about whether
the results it produces are accurate or reproducible...

-- 
Don Armstrong  http://www.donarmstrong.com

unbeingdead isn't beingalive
 -- e.e. cummings "31" _73 Poems_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140428001658.gf7...@teltox.donarmstrong.com

Re: concurrent installation of different pkg versions

[Russ Allbery]

Steve Langasek  writes:
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:

>> it would be a great advantage for Debian over the other distributions
>> to have the capacity to install multiple versions concurrently.

> No, no it wouldn't.

> This is how rpm handles library packages.  It's a horror show.

All of our research computing systems run Red Hat (or CentOS) because
that's where the people who care about concurrent installation of
different versions have gone, since no one in the Debian and Ubuntu world
with influence seems to care about their problems.  And simultaneous
installation of multiple versions of packages is simply a requirement for
many research computing scenarios, usually because there's a lot of
bespoke scientific code that accomplishes some specific goal but was not
written to the standards one would expect from professional programmers,
and therefore doesn't easily work with newer versions of libraries.

Just something to keep in mind.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87eh0kns4i@windlord.stanford.edu

Re: concurrent installation of different pkg versions

[Vincent Bernat]

 ❦ 26 avril 2014 07:07 CEST, Charles Plessy  :

> it would be a great advantage for Debian over the other distributions to have
> the capacity to install multiple versions concurrently.
>
> That does not mean that it would be a good idea to install multiple versions 
> of
> core packages.  However, on multi-user systems, the ususal approach is that 
> the
> administrator tells the users to go compile their specialised programs
> themselves.  In Debian, these programs are typically in leaf packages that 
> have
> simple dependancy trees and tend to work well unmodified on multiple releases.
>
> If we could use APT to leverage resources like snapshot.debian.org, this would
> give Debian a strong momentum on that use case.  Of course, I understand that
> implementing this properly is a lot of work.

I would be a lot simpler to leverage containers.
-- 
panic("Fod fight!");
2.2.16 /usr/src/linux/drivers/scsi/aha1542.c


signature.asc
Description: PGP signature

Re: concurrent installation of different pkg versions

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 26/04/14 07:11, Steve Langasek wrote:
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
>> Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a ￩crit :
>>> On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> 
 a generalized approach is needed.
> 
>>> Multiple versions of a package seems undesirable to me, for the
>>> same reasons as static libraries and embedded code copies are
>>> undesirable.
> 
>> Hi Paul and everybody,
> 
>> it would be a great advantage for Debian over the other
>> distributions to have the capacity to install multiple versions
>> concurrently.
> 
> No, no it wouldn't.
> 
> This is how rpm handles library packages.  It's a horror show.
> 

There is a difference between doing this for "core" packages (e.g. C
libraries, system daemons, things that are sensitive to something in
/etc) and these independent eco-systems that exist around Python,
Java, JavaScript, etc.

Letting people install arbitrary versions of Python and then expect
all the Python scripts in a stable system to just work feels unreasonable.

However, letting them install additional versions of the Python
interpreter or some Python libraries that can be used on-demand, while
not impacting the default that is used would be less demanding on
Debian to support.  The same can be said for Java and JavaScript and
other things.

With JavaScript, the problem is particularly acute because the APIs
are more volatile.  It is harder to force all web packages to use a
single version of jQuery (or something else) if each upstream uses a
different version.  Debian either ends up dropping a lot of these web
packages or demanding that DDs who want to upload such things jump
through more hoops to patch their packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTW2TGAAoJEOm1uwJp1aqDJVwQAIXaaMRQtgkXxBE+3ZfOOGly
HFWQjJ+6sX1f2xfzUCok5wyhnhQNmSCSXQ5tknEvtvJAOC5Vmb4d3fhV8knIt6HZ
QEprwYDzPeOmpxtbLQpCrGOnsIG0WcJX3Sr5DUG9g6ObJvArNTX/7sZKYLdcDZWG
FVQCLFgD6BqCXC4b0MMO6GGmb8WvnM9qz7GVgwv3JaQdlwWHzkZZ5RNRGBrN7BGS
uLqVTMWblUa8qmmhGbSNbefaOOk8rjvuKlPH0mwctcZ03K44/fr0lkoRG41bGnx/
HztaOGmGG2xOOgSbKE5oOpCCy/J/5RK2VzcFAS4NQlry+vXdHt7A/3/4UFJPTCuS
OFnEnNu7+d8bC+YtoJgVOWGncQ587eOhGhGAVnNT4Jf3VLy6F15XGoOSQmUUgCjj
Avtpmz+lFjdCmv3zCji8yw4LV/2ZANHyAWwWQAIJSQtz0+B6kQCXtaRYtBmrpHKG
bp6OIhMKtRzfsx/1Vl27ZGvbFhC2ZpRflubyNasFBD1VXbIAvsAmwGCRG3863cWS
bWY4F7Kfq0HzzDPpgan9S3Tl3XEa/HEFfRzQBtsUDNQuO1rtvQwQufhjxpXvEp5o
NnNzPxfdQHj1d3MtxuYB+VAS30kwuE9jOd/ES8jdLhyrBzq0VnGEO9+QU/CJHzPq
DgEkOPG+e3Qp9ejVOs7N
=gLWq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535b64c6.3090...@pocock.pro

Re: concurrent installation of different pkg versions

[Charles Plessy]

Le Fri, Apr 25, 2014 at 10:11:58PM -0700, Steve Langasek a écrit :
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
> > Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a écrit :
> > > On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> 
> > > > a generalized approach is needed.
> 
> > > Multiple versions of a package seems undesirable to me, for the same
> > > reasons as static libraries and embedded code copies are undesirable.
> 
> > Hi Paul and everybody,
> 
> > it would be a great advantage for Debian over the other distributions to 
> > have
> > the capacity to install multiple versions concurrently.
> 
> No, no it wouldn't.
> 
> This is how rpm handles library packages.  It's a horror show.

Hi Steve,

we have been fighting bitterly over the years, we have different points of
view, and it does not seem like we will be thiking along the same lines anytime
soon.

When you post on debian-devel or other lists and I disagree, I try to refrain
myself from juping on the keyboard and to instead give time to others to
express their disagreement.  If nobody answers, I also take it as a sign that I
probably should not answer as well.

Could I ask you to do the same for me ?

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140426052944.gd15...@falafel.plessy.net

Re: concurrent installation of different pkg versions

[Steve Langasek]

On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
> Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a écrit :
> > On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:

> > > a generalized approach is needed.

> > Multiple versions of a package seems undesirable to me, for the same
> > reasons as static libraries and embedded code copies are undesirable.

> Hi Paul and everybody,

> it would be a great advantage for Debian over the other distributions to have
> the capacity to install multiple versions concurrently.

No, no it wouldn't.

This is how rpm handles library packages.  It's a horror show.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: concurrent installation of different pkg versions

[Charles Plessy]

Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a écrit :
> On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> 
> > a generalized approach is needed.
> 
> Multiple versions of a package seems undesirable to me, for the same
> reasons as static libraries and embedded code copies are undesirable.

Hi Paul and everybody,

it would be a great advantage for Debian over the other distributions to have
the capacity to install multiple versions concurrently.

That does not mean that it would be a good idea to install multiple versions of
core packages.  However, on multi-user systems, the ususal approach is that the
administrator tells the users to go compile their specialised programs
themselves.  In Debian, these programs are typically in leaf packages that have
simple dependancy trees and tend to work well unmodified on multiple releases.

If we could use APT to leverage resources like snapshot.debian.org, this would
give Debian a strong momentum on that use case.  Of course, I understand that
implementing this properly is a lot of work.

PS: I started to read about Nix, thanks for the link.  This is exciting.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140426050722.gc15...@falafel.plessy.net

Re: concurrent installation of different pkg versions

[Paul Wise]

On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:

> a generalized approach is needed.

Multiple versions of a package seems undesirable to me, for the same
reasons as static libraries and embedded code copies are undesirable.

Systems that do this already exist though:

https://nixos.org/
http://www.gobolinux.org/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FDb90=sbd9ybs2atfsijga8y4f7_0pe31gjad6dtl...@mail.gmail.com