Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
Date: Wed, 19 Nov 2014 14:36:44
Message-Id: 546CAAED.2080200@gentoo.org
In Reply to: [gentoo-dev] [gentoo-project] Re: towards a more distributed model by Jauhien Piatlicki
1 On 11/18/2014 02:12 PM, Jauhien Piatlicki wrote:
2 >
3 > On 11/18/2014 04:19 AM, heroxbd@g.o wrote:
4 >> Jauhien Piatlicki <jauhien@g.o> writes:
5 >>
6 >>> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.
7 >>>
8 >>> Then we can have a clear understanding, how things should be: if
9 >>> something is a part of the core system, it goes to the tree, if
10 >>> something is a scientific packages, it lives in the science overlay,
11 >>> if something is a java stuff it lives in the java overlay, etc.
12 >>
13 >> This is a good idea. One difficulty: how to handle inter-overlay
14 >> dependence? Either the dependency should be expressed by overlay +
15 >> ebuild, or the dependent ebuild should be moved into the "core overlay".
16 >> I haven't figured out a clean solution yet.
17 >>
18 >
19 > Yes, this is a weak point of decentralization. We should think how to
20 > solve it. The possible solution is using of dependencies between
21 > overlays (one overlay says, it depends on other). We already have such a
22 > feature, we only need to add more support for it. Example of such a
23 > dependency:
24 >
25 > %cat /var/lib/layman/melpa-stable/metadata/layout.conf
26 >
27 > repo-name = melpa-stable
28 >
29 > masters = gnu-elpa gentoo
30 >
31 > Dependencies on overlays in ebuilds is bad idea I think, as it only will
32 > introduce additional problems. Also think what if you need not a
33 > package, but an eclass or whatever else.
34 >
35 > In addition, one question that emerges is possible circular dependencies
36 > between overlays. We need a way to handle this.
37 >
38
39 Sounds like there should be some sort of wiki page/guidelines what to
40 keep in mind when creating an overlay.
41
42 I guess there are two approaches:
43 * make the overlay as independent and consistent as possible
44 * make the overlay as themed and reusable as possible
45
46 Example: You want to create a games overlay, do you add libsdl,
47 sdl-mixer etc to it?
48
49 One way to go about it is probably to make a very strong distinction
50 between actual applications and libraries/modules.
51 So you'd rather have two overlays for the above example: "games" and
52 "games-libs"?
53
54 Similar scenarios are: do you include dev-lang/ruby in a ruby overlay,
55 dev-lang/perl in a perl overlay, dev-lang/ghc in a haskell overlay? It's
56 basically mixing toolchain with modules.
57
58 I think that's why I was previously thinking about submodules. Like
59 breaking an overlay up into smaller parts (without actually creating new
60 overlays), so that people can use specific parts of other overlays
61 without depending on the whole thing. But I'm not sure if that's a good
62 idea and although it's different, it's somewhat similar to just creating
63 a new overlay and depending on it.
64
65 In the end, I'm not sure if this is actually such a big problem. You can
66 still use random ebuilds from random overlays and commit them straight
67 to your own overlay.

Replies

Subject Author
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model Jauhien Piatlicki <jauhien@g.o>