Gentoo Archives: gentoo-dev

From: Kent Fredric <kentfredric@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage
Date: Tue, 01 Jan 2013 19:26:11
Message-Id: CAATnKFDi43z_MwPJLZjEhaARVTjekd55J_gsMef13RQCeQav0Q@mail.gmail.com
In Reply to: [gentoo-dev] [brainstorm] dev-lang internal package managers and portage by "Vadim A. Misbakh-Soloviov"
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