A repository can use metadata/layout.conf to specify that it needs eclasses from specified another repository. Example: masters = repository2 repository3 But this information is not provided in repositories.xml. I suggest: 1. Extend format of repositories.xml. Example: <repo ...> <name>repository1</name> ... <required_repos> <required_repo>repository2</required_repo> <required_repo>repository3</required_repo> </required_repos> </repo> 2. Make Layman handle dependencies on repositories. E.g. If repository1 needs repository2 and repository3, then `layman -a repository1` should add repository2 (with its dependencies), repository3 (with its dependencies) and repository1.
I think that would be stretching the role of layman beyond what it's intent was/is for. I can see a few potential problems for a start. 1) Layman does not work with any of the content of an overlay, that would be the role of the package manager. 2) the extended data can far too easily become out of sync with the actual layout.conf of the repository. So, having layman read and update that info from layout.conf after a sync of any/all of the repos could easily become a nightmare. I have experience with code like that. I do not want to go that route. That information could easily be added the the description, so that a user can see what is expected. The user can make his/her decision from there. 3) Adding in /etc/portage/repos.conf could make things even trickier. It is also something that the package managers handle already (or suppose to). So why duplicate code and try to keep them in sync. That said, the layman-2.0 api can be easily imported by the package manager and tasked to do any of layman's capabilities. It will even have a "c" interface for non-python apps (still needs updating and integration). I will be releasing a final layman-2.0.0 soon. It won't have python-3 support just yet. That should be ready for 2.0.1. I have it mostly working in py3, but some tests still fail. I also fear that there aren't enough tests to find all the py3 related bugs that I fear will crop up. So, I'm going to hold it in the -9999 version for awhile. I also need to work on the ebuild to run 2to3 on the code for any py3 installs.
Closing, too complex. nothing further brought forward to support it.