1 |
Hi Gerion,
|
2 |
|
3 |
Gerion Entrup <gerion.entrup@×××××.de> writes:
|
4 |
|
5 |
> I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of |
6 |
> interesting. However, I have a little bit the fear that a full automation |
7 |
> won't be possible and the whole project becomes a little bit like g-sorcery |
8 |
> (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a |
9 |
> large scale. |
10 |
|
11 |
Yes, that's true. I share the same observation and concern with you.
|
12 |
|
13 |
This is one exception: the CRAN ebuild generator powered R overlay has
|
14 |
been running well for 8 years.
|
15 |
|
16 |
https://wiki.gentoo.org/wiki/Project:Science/Overlay/R
|
17 |
|
18 |
> What do you think of the idea to not do this fully automated but supervised |
19 |
> by a maintainer? With that I mean an ebuild generator that generates only |
20 |
> the parts of the ebuild that it can easily parse and then present the ebuild |
21 |
> draft to a maintainer who completes it to an full ebuild. As far a I know no |
22 |
> tool like this exists. I think the focus shift helps a lot: |
23 |
> Developing a tool for the Gentoo maintainer not the Gentoo user. |
24 |
|
25 |
Yes, that makes a lot of sense. The R overlay follows this model. Most
|
26 |
of the ebuilds are automated. When an ebuild generation fails, we add
|
27 |
the ebuild manually, understand it and then update the generator to
|
28 |
cover it in the future.
|
29 |
|
30 |
> I'm only "maintaining" an overlay so maybe I'm missing experience |
31 |
> but I often have wished a tool that automatically parses the language specific |
32 |
> packaging files and is able to generate a primitive ebuild out of that. |
33 |
> Maybe it even can do this in an interactive way: |
34 |
> "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found |
35 |
> 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?" |
36 |
|
37 |
Yes, that's the way R overlay is working. And I have a similar plan and
|
38 |
proof-of-concept solution for the Java Maven overlay.
|
39 |
|
40 |
> With a not fully automatic tool also packages can be parsed that are not |
41 |
> in a complete closed ecosystem, like a 'meson.build' file or cmake files for |
42 |
> C++/C programs. But of course package databases like Maven/Cargo/Pypi are |
43 |
> also candidates. |
44 |
> |
45 |
> Unfortunately, I have no time currently to participate in the GSOC. I just |
46 |
> want to mention this here as an idea. Please comment or correct me, if |
47 |
> such a tool already exists. |
48 |
|
49 |
Thank you! Your input is really valuable.
|
50 |
|
51 |
Yours,
|
52 |
Benda |