| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 01/01/2013 02:14 PM, Vadim A. Misbakh-Soloviov wrote: |
| 5 |
> Hi there! Long time ago I discovered that many language-specific |
| 6 |
> packages (libraries, webapps) written on languages like PHP, Ruby, |
| 7 |
> Lua and so on has (often) almost hardcoded dependence to be |
| 8 |
> installed via their native package managers (pecl, cpan, luarocks, |
| 9 |
> gem, bundler and so on). More of that, I discovered quite spiked |
| 10 |
> way to install lang-specific packages in portage (fakegem eclass, |
| 11 |
> pecl-php eclass and so on). Thinking in that way guided me to |
| 12 |
> suggest to develop some kind of compatibility layer between portage |
| 13 |
> (and sandboxed installation) and that lang-specific package |
| 14 |
> managers. So then it will be almost unneeded to, for example, write |
| 15 |
> tons of new local ebuilds when installing, for example new version |
| 16 |
> of redmine. Or to write tons of spikes when installing some PHP or |
| 17 |
> Lua apps, designed for pecl or luarocks respectively. |
| 18 |
> |
| 19 |
> But on the other hand — QA issues. I afraid, that it will make us |
| 20 |
> responsible to upstream failures (in users eyes). |
| 21 |
> |
| 22 |
> Anyway, let's discuss some ideas on that behaviour. |
| 23 |
> |
| 24 |
> |
| 25 |
> BTW, this post is mainly sponsored by great PITA about deploying |
| 26 |
> rails applications and trying to get them to work with system-wide |
| 27 |
> dev-ruby/* things installed (while upstream REQUIRES to use |
| 28 |
> bundler). It is also minor-sponsored by some kepler-project apps |
| 29 |
> (Lua) and some PHP apps. |
| 30 |
|
| 31 |
I'm in the process of rolling out the latest Redmine. |
| 32 |
|
| 33 |
First, bundler et al. are happy to use the system stuff. You just need |
| 34 |
to make sure all of the dependencies for your app are installed. |
| 35 |
|
| 36 |
Your problem isn't that you need a general solution to the upstream |
| 37 |
packaging problem -- it's that redmine is basically unmaintained in |
| 38 |
Gentoo, so you have to do it yourself. And maintaining rails packages |
| 39 |
is hard, so it sucks even more that the effort is duplicated. As a |
| 40 |
user I don't care where the ebuilds come from or what they do, just |
| 41 |
that they're up-to-date, in the main tree, and work. |
| 42 |
|
| 43 |
If Redmine was being properly maintained, you could just `emerge |
| 44 |
redmine` to pull in its dependencies. Then you could download Redmine |
| 45 |
yourself, stick it somewhere, and bundler would be happy. |
| 46 |
|
| 47 |
In lieu of that, what we do is create ebuilds like |
| 48 |
www-apps/redmine-dependencies. I manually parse the Gemfile for the |
| 49 |
(R)DEPENDs. My life would be a lot easier if we had something like |
| 50 |
gentoo-haskell's hackport that could parse a Gemfile and spit out an |
| 51 |
ebuild. But in any case, it's a poor substitute for doing it right. |
| 52 |
-----BEGIN PGP SIGNATURE----- |
| 53 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 54 |
|
| 55 |
iQIcBAEBAgAGBQJQ41FCAAoJEBxJck0inpOirF4P/jQXyZyMz8Q88pQrNY5Zs2sF |
| 56 |
xgG6SvRUDO0cq73AW+M2P7GNgRHwoUGfoTb5q1C4lCbJfq3ZFUj1YKmVrTuqURo0 |
| 57 |
hfgUETWIsaV7fXS3sdkvXijT6N7tf5SHWFC9cQkP0q+T2JXwlhNZXb9gg076jofg |
| 58 |
NHNUMzKkqgWxfFLa3R2cLaCpDnB25Hug86K8heIUbQn6sH1CVu8CMYesCqFYQbms |
| 59 |
/3gyN1NDKpDSqu1TTjG0fsA1bvZjjB7Mm+crZYGvFx7pwCtX8q48eMr7dEXt7UPG |
| 60 |
TjHWBaBK5aoCIud0xHDfIjHvTIlG1LEwRhaAJjt+aVHMpNQ68ZWNZrAcOJGpEMwE |
| 61 |
2lIxgimC6M/qSsPvR3n0C9MbHDwk8gkjGMijabzGle4WZDdPnohZ8mpQuJiWtvB5 |
| 62 |
gtxi29FfYvsKQBQcVxLPYM7cMNEOq5O4BV1dqv2B9e194ONwcTLBPcenGHE1WIBP |
| 63 |
QK8xRgDqz1HoZW+av9IlhVy8BcUk8kRo3kFSC8zZG+by5L0i+sMk4EGzcJuiXxE1 |
| 64 |
cfXAiLeNtoD1NZjSutfbb55B8hdfwak3B15cH6DrZj0N6SK35+mULHiaBN9ywG5q |
| 65 |
gRUJ0HIzrzhpLRtT7ahEtqlF6lmtjYZNTyl3nmc11uyhtAjUsXH5cMT4b0m3MAz/ |
| 66 |
UJp7IGdFwG6IMQY3xI1y |
| 67 |
=kXHU |
| 68 |
-----END PGP SIGNATURE----- |
Archives