Re: concurrent installation of different pkg versions
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
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
(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 -- 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
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
-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, alast...@sceal.ie, mckins...@debian.org, 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
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
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
On Sat, Apr 26, 2014 at 06:21:33AM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org 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 fu...@yuggoth.org 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 a...@offog.org http://offog.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/y2aioprk7zx@cartman.at.offog.org
Re: OpenStack needs for backport repo (was: concurrent installation of different pkg versions)
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) For jquery, the issue is to have multiple versions of the same library installed at the same time in a single system. Since you're raising the topic, I feel like I should explain. This isn't the need of OpenStack, which is: - everyone uses Wheezy and an unofficial backport repository. - upstream is mooving too fast (6 months release cycle, deprecation of old-stable release after 10 months). - the OpenStack repository is huge (hundreds of megs), and so it makes sense to have something separate from standard backports. - all distributions are doing separate backport repos (Ubuntu cloud-archive, RedHat RDO, etc.) because of the same reasons above. This isn't new: Debian PPAMAIN would be the perfect fit. But its not looking like it's coming fast, which is why I asked the FTP masters what could be done now, though I didn't get a reply from them (too busy?). 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/53605310.4020...@debian.org
Re: concurrent installation of different pkg versions
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
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 package-version-debversion creating a virtual machine and installs package 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
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
]] 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
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
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
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
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
2014-04-28 2:16 GMT+02:00 Don Armstrong d...@debian.org: 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 d...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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
-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
❦ 26 avril 2014 07:07 CEST, Charles Plessy ple...@debian.org : 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
Steve Langasek vor...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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
concurrent installation of different pkg versions
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. Maybe it will be needed more widely though (e.g. for some Java stuff too). On the other hand, some maintainers and security team naturally don't want the hassle of supporting so many versions concurrently. With so many upstreams now including stuff like this, particularly in web software and the emergence of node.js as well, maybe a generalized approach is needed. 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) -- 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/535a9def.6050...@pocock.pro
Re: concurrent installation of different pkg versions
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
Re: concurrent installation of different pkg versions
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
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
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
