On 06-08-2011 16:17:32 -0400, James Cloos wrote: > Your idea is a step in the right direction, but the ideal config would > have a top level portage.git with sub-modules for each category, as well > as for eclass, licenses, profiles and scripts. Each category.git should > have sub-modules for each package therein.
I believe the size of a repo (how much it contains) should depend on what it is. Some packages (like e.g. Mutt) live very well on their own, I understand larger projects like GNOME and KDE prefer to have many sub-components in one repo. I don't necessarily think there should be a clear hierarchy, although subtrees may require that. > Within the profiles.git it *might* be reasonable for each directory in > arch/ also to be a sub-modules. Or not. That should be dicussed. > > And the bureaucracy should be minimal. Adding, changing or removing a > submodule from its parent repo should only require a call for consensus > among the devs, and not be pushed through a small set of devs on some > given team. Currently, all devs can add and remove (with notice) packages, so I don't see why that would require a consensus with this model, suddenly. > It may also be useful for the process which generates metadata/ to push > out to a repo, too, just before syncing out to the rsync mirrors. I don't understand what you mean by this. Can you elaborate? > Having each package in its own repo is a great idea. But a simple > recursive git pull to update the whole thing is highly desireable. > Git submodules fit the bill perfectly. I assumed something like this possible to be able to get "all" easily or something. -- Fabian Groffen Gentoo on a different level
