1 |
On 07-08-2011 00:07:41 +0530, Nirbheek Chauhan wrote: |
2 |
> On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen <grobian@g.o> wrote: |
3 |
> > In short, the repo-per-package model means that each package |
4 |
> > (my-cat/package) is a separate repository in some VCS. |
5 |
> > Instead of having a huge tree that will only grow forever (gx86), |
6 |
> > packages are just in their own repository. |
7 |
> |
8 |
> I had mixed feelings while reading your email. The idea is certainly |
9 |
> very intriguing, but there's a few things that make it a no-go for me: |
10 |
> |
11 |
> 1. One of the big things I've been looking forward to with git is the |
12 |
> ability to do atomic commits across the tree. Addition of GNOME |
13 |
> releases, pkgmove changes across the tree, changing ebuild/eclass |
14 |
> behaviour, etc. without inconsistency or praying that my connection |
15 |
> doesn't get dropped in the middle of a hundred interrelated commits. |
16 |
> Without this feature, I think some arch teams and GNOME/KDE teams will |
17 |
> become sad. |
18 |
|
19 |
I see this being possible by making a single commit to the rsync tree |
20 |
generation script. |
21 |
|
22 |
I also consider alternatives possible, as touched upon by James Cloos in |
23 |
this thread where large projects like GNOME and KDE have a single |
24 |
repository for all/most of their ebuilds, and perhaps even eclasses. |
25 |
Repo-per-package may be too finegrained for projects like these, and |
26 |
being flexible here is not going to be any problem AFAICT. |
27 |
|
28 |
> 2. The ability to do "feature" commits across the whole tree instead |
29 |
> of hundreds of tiny commits everywhere. This combined with the |
30 |
> ChangeLog generation will save a lot of time and space. This will |
31 |
> especially benefit arch teams, but I've felt the need for this |
32 |
> numerous times myself. Example: we moved to using .xz tarballs for |
33 |
> GNOME, and that touched a lot of ebuilds, and it was extremely |
34 |
> time-consuming to repeat echangelog && repoman commit per-package. |
35 |
|
36 |
Consensus is that echangelog is eventually going to disappear, IIRC, and |
37 |
repoman commit probably can be done on the entire tree/repo, with the |
38 |
help of sub-repos, or when you have a repo for full GNOME. |
39 |
|
40 |
Whether you script a loop, or make a single call to repoman, you always |
41 |
have to pay for running repoman, since it's your QA tool, that you're |
42 |
not supposed to skip/bypass. |
43 |
|
44 |
> 3. Adding packages from overlays via `cherry-pick` or `git am` will |
45 |
> become extremely tedious. If thin manifests are implemented, a series |
46 |
> of patches + a simple merge hook will be all you need to move |
47 |
> KDE/GNOME releases from the overlay to the tree. Without a single |
48 |
> tree, you need to go back to the current way of doing things. |
49 |
|
50 |
With my proposal you wouldn't do this. You would simply add a line in |
51 |
the rsync tree script for including that package. Most probably the |
52 |
package would already live on g.g.o or something Gentooish, so it |
53 |
wouldn't move at all, it would just be included. |
54 |
|
55 |
In case you would have a repo with multiple packages, you would just |
56 |
tell the script to now also include the directory where your package |
57 |
lives. |
58 |
|
59 |
> 4. We'll need to write extra tools to keep the user's cat/pkg list |
60 |
> up-to-date; adding and removing repositories as needed, etc. This is |
61 |
> added complexity for which we'll need volunteers (we've been facing a |
62 |
> manpower shortage already...) |
63 |
|
64 |
I don't understand this. Users don't see anything of this change. |
65 |
Developers could use subtrees, forests, or just only what they care |
66 |
about. |
67 |
|
68 |
> 5. The total size of the tree will increase a *lot* since all these |
69 |
> repositories will no longer share data. The current gentoo-x86 tree |
70 |
> stored in git without history takes only ~25MB because ebuilds are |
71 |
> extremely redundant. The space requirements will balloon once we need |
72 |
> to store 15,000 repositories. And arch teams will have to store *all* |
73 |
> of them, often on devices with very low space. |
74 |
|
75 |
I'm not too concerned about disk space. Cloning a repo as-needed should |
76 |
be fairly fast, and even arch teams won't need all 15,000 repositories. |
77 |
It's easy to throw away repos for packages no longer necessary too. |
78 |
For the limited disk-space arches, the specialised rsync trees do come |
79 |
in handy though. |
80 |
|
81 |
|
82 |
-- |
83 |
Fabian Groffen |
84 |
Gentoo on a different level |