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