Re: [gentoo-dev] Ebuild Generators

[Tom Gillespie <tgbugs@gmail.com>]

For historical curiosity there was also
https://github.com/domenkozar/g-pypi at one point (similar to
https://github.com/rafaelmartins/g-octave). Having used g-octave, the
primary issue is as Michał says, there are a lot of corner cases that
the generation doesn't handle correctly which lead to broken ebuilds
and maintenance headaches. Speaking for python, catching and
correcting the use of setup_requires and other insanity visited upon
us by the wonders of setuptools makes this a non-starter. If you have
a set a known sane packages you could in theory write an eclass that
captures the regularities of those packages, but I'm not sure eclasses
are suggested for that use case.
Tom

On Mon, Feb 3, 2020 at 5:27 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote:
> > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu:
> > > 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.
> > I mean only on a primitive base:
> > ```
> > if link contains "pypi":
> >     # it's a Python package from pypi
> >     handle_pypi()
> > elif work_tree contains "setup.py":
> >     # it's a Python package
> >     handle_generic_python()
> >
>
> Please don't use generators for Python.  You'd have to put a lot of
> effort to get things right.  Most of the time, you'll end up with broken
> or no tests, useless deps and py2 where unnecessary.
>
> Creating ebuilds is not a problem.  Maintaining is.  Python team ended
> up with lots of packages dumped by former project members or other
> developers.  Many of them are of very bad quality.  Even those that
> aren't are a maintenance burden.  Removing broken and/or useless
> packages is taking a lot of our time.
>
> --
> Best regards,
> Michał Górny
>