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. |