Hi anoteros, anote...@teknik.io writes:
> Having used Gentoo for a few years now, one thing that has been > annoying to me is the tremendous duplication of effort and uphill > battle of creating ebuilds (build recipes) for language-specific > packages that already have their own build systems. > > For example, many languages such as Python (pip), Node (npm), Ruby > (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of > redistributing up-to-date dependencies and ensuring that they build > properly in most environments. Portage, it seems, does not take > advantage of this at all. If I want to install the package 'foo', > which has 'bar' as a dependency (which has been installed through > cabal, for instance). Why should portage download some outdated second > copy of the sources for 'bar', rebuild it, and scatter it around the > file system where it cannot be used by other programs installed by > cabal? There have been quite a lot of effort before. What I know are: * R_Overlay R_Overlay uses roverlay[1] to generate ebuilds from CRAN and BIOC. It works for 90% of the packages, and has a dozen of users. The biggest burden of maintenance is parsing random strings upstream would put in the dependency fields (e.g. [6]). * Maven Overlay It is based on java-ebuilder[2] to generate ebuilds from Java Maven repository. The proof of concept overlay works well for Apache spark[3]. A bit of scripting resolved the incompatibility of version schemes mentioned by kentnl[5]. I am proposing a GSOC idea to mentor a student on it, https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas/Maven_Java_overlay * g-sorcery A general purpose ebuild generator in Gentoo (app-portage/g-sorcery)[4], I have been using it for pip (app-portage/gs-pypi) and elpa (app-portage/gs-elpa). It works but a bit out-of-date. Help welcome. >From my experiences with the ebuild generators, they can be made very reliable and painless. By far IMHO the R Overlay is the most successful. The overlay is generated on a server exposed into layman list. The generation process needs to be maintained and can have bugs when the upstream evolves. It can be a pain for an average user to debug. Therefore, Gentoo semi-offical automatic overlays from language-specific repositories provides a promising potential solution. Yours, Benda 1. https://github.com/dywisor, developed by dywisor as a GSOC project with calchan. 2. https://github.com/gentoo/java-ebuilder, lead by fordfrog of the Java Project. 3. https://github.com/heroxbd/maven-overlay 4. developed by jauhien as a GSOC project. 5. https://archives.gentoo.org/gentoo-dev/message/487f5eb7b2d1ba00ae607b3f88bbb8c9 6. https://github.com/dywisor/roverlay/blob/master/config/simple-deprules.d/dev-libs