On 2 January 2013 08:14, Vadim A. Misbakh-Soloviov <m...@mva.name> wrote: > Hi there! > Long time ago I discovered that many language-specific packages > (libraries, webapps) written on languages like PHP, Ruby, Lua and so on > has (often) almost hardcoded dependence to be installed via their native > package managers (pecl, cpan, luarocks, gem, bundler and so on). > More of that, I discovered quite spiked way to install lang-specific > packages in portage (fakegem eclass, pecl-php eclass and so on). > Thinking in that way guided me to suggest to develop some kind of > compatibility layer between portage (and sandboxed installation) and > that lang-specific package managers. > So then it will be almost unneeded to, for example, write tons of new > local ebuilds when installing, for example new version of redmine. Or to > write tons of spikes when installing some PHP or Lua apps, designed for > pecl or luarocks respectively. > > But on the other hand — QA issues. I afraid, that it will make us > responsible to upstream failures (in users eyes). > > Anyway, let's discuss some ideas on that behaviour. > > > BTW, this post is mainly sponsored by great PITA about deploying rails > applications and trying to get them to work with system-wide dev-ruby/* > things installed (while upstream REQUIRES to use bundler). It is also > minor-sponsored by some kepler-project apps (Lua) and some PHP apps. >
My experience with Perl is that, at least for now, what you propose is impossible. There's no "hard coded" dependence on Package Managers, its really a choice, at least, For Perl that is. Upstream Perl basically tell users: Use entirely distro tools, or use entirely perl tools, don't try mixing them. And this advice generally works out well. ie: either you rely on Gentoo mapping Perl packages to dists , or you use a user-installed copy of perl ( ie: using Perlbrew ), and leave the "System" perl to be there for other system perl stuff. Essentially, the "Perl installed by your package manager" should be used for "System Perl" tasks, ie: other programs that you happen to be running on your system that are also installed by package management. For programming and project development, its generally recommended to use a user install instead, and install that perl in ~/ , and its dependencies in ~/ , and not mingle it with system Perl. Perhaps this advice should also be more widely disseminated for other languages? I know that at least with things like Maven ( Java development ), using a system install of Maven is a nightmare and a exercise in futility, while a local user install works quite nicely. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
