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. Ma
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
-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
>
Check out modules and lmod for this:
http://modules.sourceforge.net
https://github.com/TACC/Lmod
Cheers,
Steve
(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?).
B
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
>
On 04/26/2014 01:39 AM, Daniel Pocock wrote:
> There was even a debate about this on the backports list recently in the
> context of how to support different versions of OpenStack (not installed
> concurrently though, but just making perhaps the most recent 2 releases
> available to users on wheezy
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
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
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
ar
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
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 an
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 t
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:
]] 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 b
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 y
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
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
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
>> s
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 sta
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.
❦ 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,
-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 generali
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 nee
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 sam
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 undesir
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
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
and friends all installed concurrently. Ma
28 matches
Mail list logo
