Hacker News new | past | comments | ask | show | jobs | submit login

This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite language and especially the scripting ones and virtual machines one will have there own repositories that are _not_ linked into the systems way of doing things.

So at the system level we have RPM and Yum and Ports and Portage and Macports and Fink and Homebrew and AptGet and Conary and yada yada yada but at the language level we have (deep breath) Perl and CPAN, Ruby and GEMS, Python and EGGS, and Emacs and ? and Java and Eclipse plugins and on and on.

I would switch IN AN INSTANT to the distro that integrated all this so that I would only need to go to ONE place to upgrade system packages and language packages. Honestly if nobody does it one of these years I might even be forced to do it myself and make mega $ € ¥.

Hope this makes sense to somebody somewhere. :)




    have there own repositories that are _not_ linked into the systems way of doing things
One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this.

I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when the distro upgrades it's copy (or switch to the next 6-month release with Ubuntu and similar).


I've no direct experience of Arch, but the traditional problem with integrating rubygems is that it expects to be able to install more than one version side-by-side. That's alien enough from the packge management point of view, but when it's de facto idiomatic to specify required versions and manipulate the load path at runtime, it makes integrating with a distro downright fiddly.


Indeed. This is why I would never install Eclipse from synaptic on Ubuntu because the Ubuntu schedules and Eclipse schedules differed. And perhaps they wouldn't coincide anyway even if they synchronised temporally. Which means that someone somewhere is wasting there time packaging Eclipse for Debian/Ubuntu.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: