1 |
Having used Gentoo for a few years now, one thing that has been annoying |
2 |
to me is the tremendous duplication of effort and uphill battle of |
3 |
creating ebuilds (build recipes) for language-specific packages that |
4 |
already have their own build systems. |
5 |
|
6 |
For example, many languages such as Python (pip), Node (npm), Ruby |
7 |
(gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of |
8 |
redistributing up-to-date dependencies and ensuring that they build |
9 |
properly in most environments. Portage, it seems, does not take |
10 |
advantage of this at all. If I want to install the package 'foo', which |
11 |
has 'bar' as a dependency (which has been installed through cabal, for |
12 |
instance). Why should portage download some outdated second copy of the |
13 |
sources for 'bar', rebuild it, and scatter it around the file system |
14 |
where it cannot be used by other programs installed by cabal? |
15 |
|
16 |
It seems reasonable to me to 'hook' portage into these other package |
17 |
managers, so that running 'emerge bar' would actually run 'cabal install |
18 |
bar' rather than downloading sources and running 'ghc'. This would make |
19 |
managing dependencies much easier as versions change, since most (all?) |
20 |
these alternate package managers have ways of specifying specific |
21 |
versions of packages or pinning. It would also put an end to the |
22 |
breakage caused by, for example, running 'pip' as root and breaking all |
23 |
the python libraries portage has pulled in. |
24 |
|
25 |
I also notice that there is a GSoC 2018 project for integrating Rust |
26 |
more closely within Gentoo. It seems to me that allowing ebuilds to be |
27 |
written like this would help resolve this not only for Rust, but for all |
28 |
languages with similar build systems (which is most modern languages, |
29 |
frankly). |
30 |
|
31 |
The only real issue I see with this is the potential loss of granularity |
32 |
with USE flags for some of these packages, but having poked around the |
33 |
sort of language-specific libraries and bindings available, hardly any |
34 |
have any USE flags available, and those that do only offer debug symbols |
35 |
or documentation, which many of these other build systems offer as well, |
36 |
so I doubt this would be an issue for anyone. I could of course be wrong. |
37 |
|
38 |
Is this a feature/improvement other Gentoo users/developers would be |
39 |
interested in? If so, I would love to help discuss and potentially help |
40 |
with its implementation. |