Re: [gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

2020-02-03 Thread Gerion Entrup
Am Montag, 3. Februar 2020, 05:20:42 CET schrieb Benda Xu:
> Gerion Entrup  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
Hmm, interesting, thank you.


> > 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.
Is this possible in all cases? I think of adding custom patches,
appropriate mapping of dependencies, check for things like desktop icon
cache...


> > 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.
Nice to hear. I think, it is meaningful to solve all generation with one
tool. Maybe it can even "recognize" the used build system and package
database. Is this your plan, too?


Best,
Gerion


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

2020-02-02 Thread Benda Xu
Hi Gerion,

Gerion Entrup  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


signature.asc
Description: PGP signature