Hi Gerion,

Gerion Entrup <gerion.entrup@flump.de> writes:

> I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of
> interesting. However, I have a little bit the fear that a full automation
> won't be possible and the whole project becomes a little bit like g-sorcery
> (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a
> large scale.

Yes, that's true.  I share the same observation and concern with you.

This is one exception: the CRAN ebuild generator powered R overlay has
been running well for 8 years.

  https://wiki.gentoo.org/wiki/Project:Science/Overlay/R

> What do you think of the idea to not do this fully automated but supervised
> by a maintainer? With that I mean an ebuild generator that generates only
> the parts of the ebuild that it can easily parse and then present the ebuild
> draft to a maintainer who completes it to an full ebuild. As far a I know no
> tool like this exists. I think the focus shift helps a lot:
> Developing a tool for the Gentoo maintainer not the Gentoo user.

Yes, that makes a lot of sense.  The R overlay follows this model.  Most
of the ebuilds are automated.  When an ebuild generation fails, we add
the ebuild manually, understand it and then update the generator to
cover it in the future.

> I'm only "maintaining" an overlay so maybe I'm  missing experience
> but I often have wished a tool that automatically parses the language specific
> packaging files and is able to generate a primitive ebuild out of that.
> Maybe it even can do this in an interactive way:
> "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"

Yes, that's the way R overlay is working.  And I have a similar plan and
proof-of-concept solution for the Java Maven overlay.

> With a not fully automatic tool also packages can be parsed that are not
> in a complete closed ecosystem, like a 'meson.build' file or cmake files for
> C++/C programs. But of course package databases like Maven/Cargo/Pypi are
> also candidates.
>
> Unfortunately, I have no time currently to participate in the GSOC. I just
> want to mention this here as an idea. Please comment or correct me, if
> such a tool already exists.

Thank you!  Your input is really valuable.

Yours,
Benda