1 |
(re-sending since I sent it using my gentoo account the first time; |
2 |
but I'm subscribed with my gmail acount) |
3 |
|
4 |
Since we're closer to completing the git migration now, I feel this |
5 |
should be brought up again to discuss the best way of going about with |
6 |
it. |
7 |
|
8 |
Below is what I'm proposing; feel free to pick holes in it :) |
9 |
|
10 |
======= |
11 |
Concept: |
12 |
======= |
13 |
* Store only DIST checksums in Manifest for git |
14 |
- Due to the distributed nature of git, to do mischief, you need to |
15 |
change every clone in the world to be successful |
16 |
- This has nothing to do with strength of the hash used by git |
17 |
* Needs to be done after the move to git (see "Migration:" below) |
18 |
* User's rsync-ed portage still needs full Manifests (see "How:" below) |
19 |
|
20 |
-> Anything else that should be a part of this? |
21 |
|
22 |
========== |
23 |
Advantages: |
24 |
========== |
25 |
* Saves an extra step for the developer while testing |
26 |
- *edit* *manifest* *test* => *edit* *test* |
27 |
* Reduces conflicts |
28 |
- Especially helpful in very active overlays where merging takes place |
29 |
* Doesn't store redundant data |
30 |
- git's workflow already ensures the integrity of content due to the |
31 |
distributed nature |
32 |
- No need to store checksums for files stored in the tree |
33 |
|
34 |
-> Any other advantages? |
35 |
|
36 |
==== |
37 |
How: |
38 |
==== |
39 |
* EBUILD/MISC/AUX checksums are not stored in the git tree |
40 |
- Generate them on the rsync side before distribution |
41 |
* Portage support for thin manifests |
42 |
- If Manifest contains *only* DIST checksums *and* the tree is a |
43 |
dvcs tree; use only those |
44 |
+ This is for local testing by devs, and overlays |
45 |
+ Make emerge check if the $dvcs tree has conflicts and warn/error |
46 |
out (optional) |
47 |
~ Since we don't have file manifests, portage leaves the work |
48 |
of verification to the dvcs |
49 |
~ If the dvcs is in an uncertain state, portage should detect that |
50 |
> Might want to skip if there are performance problems |
51 |
- If Manifest contains any other checksums; old behaviour |
52 |
+ Users of rsync portage will see no change |
53 |
|
54 |
-> Anything else that needs to be done? |
55 |
|
56 |
======== |
57 |
Migration: |
58 |
======== |
59 |
* We tell all devs to move to a newer portage immediately after the |
60 |
git conversion |
61 |
- Release a new version of portage much before the migration to git |
62 |
with support for all this |
63 |
- All Manifests in-tree are pruned in one massive commit after the |
64 |
conversion to git, and before opening the tree for dev push use. |
65 |
- Push hook to reject commits with old manifests |
66 |
* Overlay users |
67 |
- Overlay users will have to move to a newer portage which supports |
68 |
thin manifests |
69 |
- Need to find a way to inform users of this |
70 |
|
71 |
-> Anything else in migration? |
72 |
|
73 |
=========== |
74 |
Compatibility: |
75 |
=========== |
76 |
|
77 |
* Compatible with Manifest2 (per-category manifests) |
78 |
* Per-dev signed commits become obsolete since we most of the |
79 |
checksums are generated during rsync conversion |
80 |
- Aim of signed commits is to stop MITM attacks on rsync mirrors |
81 |
- With Manifest2, we can sign the grouped Manifest with a "Gentoo" gpg key |
82 |
+ This alleviates MITM attacks |
83 |
|
84 |
-> Any other Manifest-related proposals this might conflict with? |
85 |
|
86 |
====== |
87 |
Coding: |
88 |
====== |
89 |
* Portage support for thin manifests |
90 |
- Most important; a release must be done atleast 1 month before the migration |
91 |
- Testing can be done with overlays |
92 |
* Repoman support for thin manifests |
93 |
- Testing can be done with overlays |
94 |
* Push hooks to reject old-style manifests |
95 |
* Rsync-side scripts for generation of "Fat" Manifests |
96 |
* Rsync-side scripts for "Gentoo" signing of Manifests (conditional) |
97 |
|
98 |
-> Anything else that needs coding? |
99 |
|
100 |
-- |
101 |
~Nirbheek Chauhan |
102 |
|
103 |
Gentoo GNOME+Mozilla Team |