Am Montag, 3. Februar 2020, 05:20:42 CET schrieb Benda Xu: > Gerion Entrup <gerion.ent...@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 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.
