| 1 |
Hi anoteros, |
| 2 |
|
| 3 |
anoteros@××××××.io writes: |
| 4 |
|
| 5 |
> Having used Gentoo for a few years now, one thing that has been |
| 6 |
> annoying to me is the tremendous duplication of effort and uphill |
| 7 |
> battle of creating ebuilds (build recipes) for language-specific |
| 8 |
> packages that already have their own build systems. |
| 9 |
> |
| 10 |
> For example, many languages such as Python (pip), Node (npm), Ruby |
| 11 |
> (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of |
| 12 |
> redistributing up-to-date dependencies and ensuring that they build |
| 13 |
> properly in most environments. Portage, it seems, does not take |
| 14 |
> advantage of this at all. If I want to install the package 'foo', |
| 15 |
> which has 'bar' as a dependency (which has been installed through |
| 16 |
> cabal, for instance). Why should portage download some outdated second |
| 17 |
> copy of the sources for 'bar', rebuild it, and scatter it around the |
| 18 |
> file system where it cannot be used by other programs installed by |
| 19 |
> cabal? |
| 20 |
|
| 21 |
There have been quite a lot of effort before. What I know are: |
| 22 |
|
| 23 |
* R_Overlay |
| 24 |
|
| 25 |
R_Overlay uses roverlay[1] to generate ebuilds from CRAN and BIOC. It |
| 26 |
works for 90% of the packages, and has a dozen of users. |
| 27 |
|
| 28 |
The biggest burden of maintenance is parsing random strings upstream |
| 29 |
would put in the dependency fields (e.g. [6]). |
| 30 |
|
| 31 |
|
| 32 |
* Maven Overlay |
| 33 |
|
| 34 |
It is based on java-ebuilder[2] to generate ebuilds from Java Maven |
| 35 |
repository. The proof of concept overlay works well for Apache |
| 36 |
spark[3]. |
| 37 |
|
| 38 |
A bit of scripting resolved the incompatibility of version schemes |
| 39 |
mentioned by kentnl[5]. |
| 40 |
|
| 41 |
I am proposing a GSOC idea to mentor a student on it, |
| 42 |
|
| 43 |
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas/Maven_Java_overlay |
| 44 |
|
| 45 |
* g-sorcery |
| 46 |
|
| 47 |
A general purpose ebuild generator in Gentoo (app-portage/g-sorcery)[4], |
| 48 |
I have been using it for pip (app-portage/gs-pypi) and elpa |
| 49 |
(app-portage/gs-elpa). It works but a bit out-of-date. Help welcome. |
| 50 |
|
| 51 |
|
| 52 |
From my experiences with the ebuild generators, they can be made very |
| 53 |
reliable and painless. |
| 54 |
|
| 55 |
By far IMHO the R Overlay is the most successful. The overlay is |
| 56 |
generated on a server exposed into layman list. The generation process |
| 57 |
needs to be maintained and can have bugs when the upstream evolves. It |
| 58 |
can be a pain for an average user to debug. |
| 59 |
|
| 60 |
Therefore, Gentoo semi-offical automatic overlays from language-specific |
| 61 |
repositories provides a promising potential solution. |
| 62 |
|
| 63 |
Yours, |
| 64 |
Benda |
| 65 |
|
| 66 |
1. https://github.com/dywisor, developed by dywisor as a GSOC project |
| 67 |
with calchan. |
| 68 |
|
| 69 |
2. https://github.com/gentoo/java-ebuilder, lead by fordfrog of the Java |
| 70 |
Project. |
| 71 |
|
| 72 |
3. https://github.com/heroxbd/maven-overlay |
| 73 |
|
| 74 |
4. developed by jauhien as a GSOC project. |
| 75 |
|
| 76 |
5. https://archives.gentoo.org/gentoo-dev/message/487f5eb7b2d1ba00ae607b3f88bbb8c9 |
| 77 |
|
| 78 |
6. https://github.com/dywisor/roverlay/blob/master/config/simple-deprules.d/dev-libs |
Archives