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.
Reply to: