Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Ebuild Generators
Date: Mon, 03 Feb 2020 13:26:48
Message-Id: f1346a463cb0f3165281b56338f7073d4cc106aa.camel@gentoo.org
In Reply to: Re: [gentoo-dev] Ebuild Generators by Gerion Entrup
1 On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote:
2 > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu:
3 > > Hi Gerion,
4 > >
5 > > Gerion Entrup <gerion.entrup@×××××.de> writes:
6 > >
7 > > > > Yes, that makes a lot of sense. The R overlay follows this model. Most
8 > > > > of the ebuilds are automated. When an ebuild generation fails, we add
9 > > > > the ebuild manually, understand it and then update the generator to
10 > > > > cover it in the future.
11 > > >
12 > > > Is this possible in all cases? I think of adding custom patches,
13 > > > appropriate mapping of dependencies, check for things like desktop
14 > > > icon cache...
15 > >
16 > > That's too complex to handle automatically. Luckily, in R overlay, such
17 > > packages are less than 5%. An ebuild generator is based on the
18 > > observation that many language-specific packages are trivial to fetch,
19 > > compile and install.
20 > >
21 > > > > > I'm only "maintaining" an overlay so maybe I'm missing experience
22 > > > > > but I often have wished a tool that automatically parses the language specific
23 > > > > > packaging files and is able to generate a primitive ebuild out of that.
24 > > > > > Maybe it even can do this in an interactive way:
25 > > > > > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
26 > > > > > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
27 > > > >
28 > > > > Yes, that's the way R overlay is working. And I have a similar plan and
29 > > > > proof-of-concept solution for the Java Maven overlay.
30 > > >
31 > > > Nice to hear. I think, it is meaningful to solve all generation with one
32 > > > tool. Maybe it can even "recognize" the used build system and package
33 > > > database. Is this your plan, too?
34 > >
35 > > No, I don't think it possible as far as I can see... That would be a
36 > > strong AI.
37 > I mean only on a primitive base:
38 > ```
39 > if link contains "pypi":
40 > # it's a Python package from pypi
41 > handle_pypi()
42 > elif work_tree contains "setup.py":
43 > # it's a Python package
44 > handle_generic_python()
45 >
46
47 Please don't use generators for Python. You'd have to put a lot of
48 effort to get things right. Most of the time, you'll end up with broken
49 or no tests, useless deps and py2 where unnecessary.
50
51 Creating ebuilds is not a problem. Maintaining is. Python team ended
52 up with lots of packages dumped by former project members or other
53 developers. Many of them are of very bad quality. Even those that
54 aren't are a maintenance burden. Removing broken and/or useless
55 packages is taking a lot of our time.
56
57 --
58 Best regards,
59 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Ebuild Generators Tom Gillespie <tgbugs@×××××.com>