Re: [gentoo-dev] Ebuild Generators

[Michael 'veremitz' Everitt <gentoo@veremit.xyz>]

[-- Attachment #1.1: Type: text/plain, Size: 1768 bytes --]

On 03/02/20 12:19, Benda Xu wrote:
> Hi Gerion,
>
> Gerion Entrup <gerion.entrup@flump.de> writes:
>
>>> 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...
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
>
>>>> 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?
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
>
> Yours,
> Benda
There was some interest in doing this for PyPI packages for Liguros linux.
See https://gitlab.com/liguros/bugs/issues/75 .


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]