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