On 11/18/2014 02:12 PM, Jauhien Piatlicki wrote: > > On 11/18/2014 04:19 AM, hero...@gentoo.org wrote: >> Jauhien Piatlicki <jauh...@gentoo.org> writes: >> >>> It would be probably good to have in the tree only the core components and >>> move other stuff to the thematic overlays. >>> >>> Then we can have a clear understanding, how things should be: if >>> something is a part of the core system, it goes to the tree, if >>> something is a scientific packages, it lives in the science overlay, >>> if something is a java stuff it lives in the java overlay, etc. >> >> This is a good idea. One difficulty: how to handle inter-overlay >> dependence? Either the dependency should be expressed by overlay + >> ebuild, or the dependent ebuild should be moved into the "core overlay". >> I haven't figured out a clean solution yet. >> > > Yes, this is a weak point of decentralization. We should think how to > solve it. The possible solution is using of dependencies between > overlays (one overlay says, it depends on other). We already have such a > feature, we only need to add more support for it. Example of such a > dependency: > > %cat /var/lib/layman/melpa-stable/metadata/layout.conf > > repo-name = melpa-stable > > masters = gnu-elpa gentoo > > Dependencies on overlays in ebuilds is bad idea I think, as it only will > introduce additional problems. Also think what if you need not a > package, but an eclass or whatever else. > > In addition, one question that emerges is possible circular dependencies > between overlays. We need a way to handle this. >
Sounds like there should be some sort of wiki page/guidelines what to keep in mind when creating an overlay. I guess there are two approaches: * make the overlay as independent and consistent as possible * make the overlay as themed and reusable as possible Example: You want to create a games overlay, do you add libsdl, sdl-mixer etc to it? One way to go about it is probably to make a very strong distinction between actual applications and libraries/modules. So you'd rather have two overlays for the above example: "games" and "games-libs"? Similar scenarios are: do you include dev-lang/ruby in a ruby overlay, dev-lang/perl in a perl overlay, dev-lang/ghc in a haskell overlay? It's basically mixing toolchain with modules. I think that's why I was previously thinking about submodules. Like breaking an overlay up into smaller parts (without actually creating new overlays), so that people can use specific parts of other overlays without depending on the whole thing. But I'm not sure if that's a good idea and although it's different, it's somewhat similar to just creating a new overlay and depending on it. In the end, I'm not sure if this is actually such a big problem. You can still use random ebuilds from random overlays and commit them straight to your own overlay.
