| 1 |
On 11/18/2014 04:19 AM, heroxbd@g.o wrote: |
| 2 |
> Jauhien Piatlicki <jauhien@g.o> writes: |
| 3 |
> |
| 4 |
>> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays. |
| 5 |
>> |
| 6 |
>> Then we can have a clear understanding, how things should be: if |
| 7 |
>> something is a part of the core system, it goes to the tree, if |
| 8 |
>> something is a scientific packages, it lives in the science overlay, |
| 9 |
>> if something is a java stuff it lives in the java overlay, etc. |
| 10 |
> |
| 11 |
> This is a good idea. One difficulty: how to handle inter-overlay |
| 12 |
> dependence? Either the dependency should be expressed by overlay + |
| 13 |
> ebuild, or the dependent ebuild should be moved into the "core overlay". |
| 14 |
> I haven't figured out a clean solution yet. |
| 15 |
> |
| 16 |
|
| 17 |
Yes, this is a weak point of decentralization. We should think how to |
| 18 |
solve it. The possible solution is using of dependencies between |
| 19 |
overlays (one overlay says, it depends on other). We already have such a |
| 20 |
feature, we only need to add more support for it. Example of such a |
| 21 |
dependency: |
| 22 |
|
| 23 |
%cat /var/lib/layman/melpa-stable/metadata/layout.conf |
| 24 |
|
| 25 |
repo-name = melpa-stable |
| 26 |
|
| 27 |
masters = gnu-elpa gentoo |
| 28 |
|
| 29 |
Dependencies on overlays in ebuilds is bad idea I think, as it only will |
| 30 |
introduce additional problems. Also think what if you need not a |
| 31 |
package, but an eclass or whatever else. |
| 32 |
|
| 33 |
In addition, one question that emerges is possible circular dependencies |
| 34 |
between overlays. We need a way to handle this. |
| 35 |
|
| 36 |
-- |
| 37 |
Jauhien |
Archives