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

Reply via email to