Hello gentoo devs. The other day I made a feature suggestion to the eselect
repository github page. (Here's the link:
https://github.com/projg2/eselect-repository/issues/20).
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