Michał Górny suggested that I should contact the gentoo-dev mailing list with my suggestion, so here it is: My suggestion is to make it possible for eselect repository to manage overlay dependencies.
As it stands, and as far as I'm concerned, there is no "proper" way of having an ebuild dependency from another overlay. So overlay writers have to copy ebuilds from other overlays or rewrite them. This implies synchronization issues (where the "copied" ebuilds get out of sync from the original ebuild) and time loss (people writing the same ebuild more than once).
Michał Górny suggested that I should make an edit to the repositories.xml file in order to tackle the issue.
This is my general idea:
(I am using the github template as an example, but the idea should apply to all other templates. I got this file from https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml).
* GITHUB TEMPLATE
<repo quality="experimental" status="unofficial">
<name>XXXXX</name>
<description lang="en">XXXXXX</description>
<homepage>https://github.com/XXXX/xxxx</homepage>
<owner type="person">
<email>XXXXX</email>
<name>XXXXX</name>
</owner>
<source type="git">https://github.com/XXXX/xxxx.git</source>
<source type="git">git+ssh://git@github.com/XXXX/xxxx.git</source>
<feed>https://github.com/XXXX/xxxx/commits/master.atom</feed>
<dependencies>
<name>overlayName</name>
</dependencies>
</repo>
(the only thing I added is the <dependencies> item)
The <dependencies> item would be a list of overlay dependencies (it could be empty). It would be represented as a list of repository names that the overlay depends on. Said dependencies could be stated in the master file (since this would "extend" its behavior)
The algorithm would use a queue ("dependencies" queue) and a set ("overlays to be added" set)
It starts by creating the "dependency" queue. After that it adds to the queue the overlay the user specifically asked for.
The dependency algorithm would look like this:
1. If the queue is empty the algorithm stops
2. Checks the first overlay in the queue's dependencies list
3. If the dependencies list is empty, it does nothing
4. If it says that there is a dependency that the user has already enabled in their system, it does nothing
5. If the dependency is already in the set of "overlays to be added", it does nothing*
6. If not 2 or 3 or 4, it adds the dependency to the set of "overlays To be added" and adds said repository to the queue
7. It "pops" the first item on the queue and repeats the algorithm
*There reason why it is a set is because there is no need to check for circular dependencies in overlays.
Once the algorithm is finished it would print out something like this
foo overlay (the one the user wants to add) depends on bar overlay.
Would you like to add bar as well? Y/N
If yes:
bar overlay depends on biz overlay.
Would you like to add biz as well? Y/N
And so on
------
PROS: Fairly simple algorithm.
CONS: Unwanted overlays with packages the user will never use.
The main con is that even though the overlay is marked as "dependency", not *all* packages depend on the other overlays: Only a few.
Having said that, this can be mitigated with only minimal manual intervention by the user.
I would love to get feedback on this idea and what are some of its shortcomings/things that I missed/haven't considered yet.
Thanks in advance and thank you for making gentoo so great.
Have a good day
- Tomas Fabrizio Orsi a.k.a Lima Limon