1 |
Hey, |
2 |
|
3 |
On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen <grobian@g.o> wrote: |
4 |
> In this email, I step away from the current model that Gentoo uses for |
5 |
> the gentoo-x86 repository. Instead, I consider a repo-per-package |
6 |
> model, as in use by e.g. Fedora [1] and Debian [2]. |
7 |
> |
8 |
> In short, the repo-per-package model means that each package |
9 |
> (my-cat/package) is a separate repository in some VCS. |
10 |
> Instead of having a huge tree that will only grow forever (gx86), |
11 |
> packages are just in their own repository. |
12 |
> |
13 |
|
14 |
I had mixed feelings while reading your email. The idea is certainly |
15 |
very intriguing, but there's a few things that make it a no-go for me: |
16 |
|
17 |
1. One of the big things I've been looking forward to with git is the |
18 |
ability to do atomic commits across the tree. Addition of GNOME |
19 |
releases, pkgmove changes across the tree, changing ebuild/eclass |
20 |
behaviour, etc. without inconsistency or praying that my connection |
21 |
doesn't get dropped in the middle of a hundred interrelated commits. |
22 |
|
23 |
Without this feature, I think some arch teams and GNOME/KDE teams will |
24 |
become sad. |
25 |
|
26 |
2. The ability to do "feature" commits across the whole tree instead |
27 |
of hundreds of tiny commits everywhere. This combined with the |
28 |
ChangeLog generation will save a lot of time and space. This will |
29 |
especially benefit arch teams, but I've felt the need for this |
30 |
numerous times myself. Example: we moved to using .xz tarballs for |
31 |
GNOME, and that touched a lot of ebuilds, and it was extremely |
32 |
time-consuming to repeat echangelog && repoman commit per-package. |
33 |
|
34 |
3. Adding packages from overlays via `cherry-pick` or `git am` will |
35 |
become extremely tedious. If thin manifests are implemented, a series |
36 |
of patches + a simple merge hook will be all you need to move |
37 |
KDE/GNOME releases from the overlay to the tree. Without a single |
38 |
tree, you need to go back to the current way of doing things. |
39 |
|
40 |
4. We'll need to write extra tools to keep the user's cat/pkg list |
41 |
up-to-date; adding and removing repositories as needed, etc. This is |
42 |
added complexity for which we'll need volunteers (we've been facing a |
43 |
manpower shortage already...) |
44 |
|
45 |
5. The total size of the tree will increase a *lot* since all these |
46 |
repositories will no longer share data. The current gentoo-x86 tree |
47 |
stored in git without history takes only ~25MB because ebuilds are |
48 |
extremely redundant. The space requirements will balloon once we need |
49 |
to store 15,000 repositories. And arch teams will have to store *all* |
50 |
of them, often on devices with very low space. |
51 |
|
52 |
The per-package models looks very neat and tidy in some respects, but |
53 |
the loss of a common git repository is too great, IMO. |
54 |
|
55 |
-- |
56 |
~Nirbheek Chauhan |
57 |
|
58 |
Gentoo GNOME+Mozilla Team |