1 |
On Friday 05 August 2005 11:42, Alec Warner wrote: |
2 |
> Whoopse, should have gone to gentoo-portage-dev, my bad ;) |
3 |
> |
4 |
> Alec Warner wrote: |
5 |
> > This is basically a resubmission of Genone's file format merger [1]. |
6 |
> > |
7 |
> > The code to handle digests and manifests is currently being designed |
8 |
> > and rewritten. As such we need two things from the developer |
9 |
> > community. One is a decision of what the new format will entail. Two |
10 |
> > is a firm agreement on the migration plan. |
11 |
> > |
12 |
> > 1. The file format is specified in Genone's original mail, but I'll go |
13 |
> > over it again to save you the extra linkage ;) |
14 |
> > |
15 |
> > Inside of the digest-manifest we have: |
16 |
> > EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1 |
17 |
> > <type> <filename> <size-tag> <size> <hash-tag> <value> <hash-tag> |
18 |
> > <value>.... |
19 |
> > Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc) |
20 |
> > |
21 |
> > *Note, that the size-tag was added to make the human parsing easier. |
22 |
|
23 |
That's incorrect. It was added because there is nothing special about size |
24 |
other than it being another way to improve your percentage of chance that |
25 |
the file you have matches. |
26 |
|
27 |
> > 2. If you didn't notice by now, this format breaks versions of portage |
28 |
> > that don't support it ( ie 2.0.X ). This leads us to a few options as |
29 |
> > users migrate to a version of portage that supports the new file |
30 |
> > format. |
31 |
> > |
32 |
> > A. Write some code into the final stable version to do both kind of |
33 |
> > formats and/or use the new format style but fall back to the old style |
34 |
> > ( since at release time the new style format probably won't be in the |
35 |
> > tree yet ). Either way, the last release of 2.0.X should work with the |
36 |
> > new file format in enough of a fashion to not break. This means that |
37 |
> > when the old manifest + digests are combined in the tree, most users |
38 |
> > should be ok even if they aren't upgraded to 2.1.X. |
39 |
> > |
40 |
> > B. Have a migration time where both formats are in the tree. For a |
41 |
> > while the tree will be larger, and many people will have issues with |
42 |
> > this. However, old portage will use the old files, and new releases |
43 |
> > will use the new files. Then after a period of however long ( 6 |
44 |
> > months? ) announce loudly beforehand that portage-2.0.X will no longer |
45 |
> > be supported and pull the old digests/manifests out of the tree. |
46 |
> > |
47 |
> > C. The Carpaski way ;)[2] Add support for the new format in 2.1, |
48 |
> > while also adding support for current format. Force everyone to |
49 |
> > upgrade to 2.1.X, while announcing that 2.0.X will not work in the |
50 |
> > future. When we have confidence that most users are upgraded, pull the |
51 |
> > old format and add the new format to the tree. |
52 |
> > |
53 |
> > Problems with all of these include the same problems as the cascaded |
54 |
> > profiles, some goofball doesn't upgrade for a year, syncs with new |
55 |
> > digests...how does he get his portage upgraded? An upgrade path should |
56 |
> > be provided and documented in this case. |
57 |
> > |
58 |
> > The best route is probably some combination of the above. |
59 |
> > Pre-emptively add support for the new format to stable, while |
60 |
> > announcing the death of the old format after 2.1's release. When most |
61 |
> > users upgrade normally to the latest 2.0.X series ( perhaps fearing the |
62 |
> > changes of 2.1.X ) they will gain support for the new file format (or |
63 |
> > if not support, merely a working portage instead of broken). We should |
64 |
> > catch the majority of users who upgrade with either the last 2.0.X |
65 |
> > release or the new release of 2.1.X. |
66 |
> > |
67 |
> > Suggestions, criticisms, etc... welcome. |
68 |
|
69 |
This stuff is all going into the Manifest rather than per ebuild digests, |
70 |
right? Portage already ignores any line in Manifest that does not begin |
71 |
with MD5. Manifests can be easily bypassed with FEATURES="-strict" anyway. |
72 |
The only real issue is SRC_URI files. An upgrade path can be made available |
73 |
by maintaining the digest.* files only for portage. |
74 |
|
75 |
There are/will be several more issues like these. The idea is already to |
76 |
have an ebuild format tag that portage will either be able to handle or |
77 |
not. How about just patching stable to not allow merging of any ebuild that |
78 |
has the tag defined and requesting the user to upgrade? |
79 |
|
80 |
In this case, the new portage would need to support both formats but the |
81 |
tree wouldn't require them both formats. The new commit tool would generate |
82 |
an old style manifest/digest for old ebuilds and new style for new ones. |
83 |
|
84 |
-- |
85 |
Jason Stubbs |