1 |
oops, sent with wrong address the first time. |
2 |
|
3 |
---------- Forwarded message ---------- |
4 |
From: Alec Warner <antarus@×××××××××××.com> |
5 |
Date: May 8, 2007 9:09 PM |
6 |
Subject: [RFC - Moving categories around] |
7 |
To: gentoo-dev@g.o |
8 |
|
9 |
So a random thought I had was 'lets move categories out of gentoo-x86/ and |
10 |
into gentoo-x86/ebuilds/' |
11 |
|
12 |
The existing layout is: |
13 |
|
14 |
gentoo-x86/ |
15 |
- <category1>/<pn...>/<ebuilds + misc stuff> |
16 |
- <category2>/<pn...>/<ebuilds + misc stuff> |
17 |
..... |
18 |
- <categoryN>/<pn...>/<ebuilds + misc stuff> |
19 |
- profiles/ |
20 |
- scripts/ |
21 |
- metadata/ |
22 |
- eclass/ |
23 |
- distfiles/ |
24 |
- local/* |
25 |
- licenses/* |
26 |
|
27 |
The new layout would be: |
28 |
gentoo-x86/ |
29 |
- profiles/ |
30 |
- scripts/ |
31 |
- metadata/ |
32 |
- eclass/ |
33 |
- licenses/ |
34 |
- ebuilds/<category...>/<pn...>/...and so forth |
35 |
- local/* |
36 |
- distfiles/* |
37 |
|
38 |
(* indicates a common directory for rsync users). |
39 |
|
40 |
The benefits include making the layout cleaner, obsoleting the categories |
41 |
file. |
42 |
|
43 |
The risks primarily include breaking a bunch of crappy old tools, as well as |
44 |
all existing package managers and user installations for those users who |
45 |
have not upgraded. |
46 |
|
47 |
I would personally fix portage and anything in gentoolkit and |
48 |
gentoolkit-dev. |
49 |
|
50 |
This change would involve breaking all old installations of gentoo that |
51 |
still sync the tree for updates such as GLSA's but don't upgrade their |
52 |
package manager to a version that supports the new ebuild locations. I |
53 |
don't really know how we support those users at present. |
54 |
|
55 |
An upgrade path would need to be provided, particularly the user must be |
56 |
able to use an older version of a package manager in conjunction with an |
57 |
ebuild to upgrade itself to a version that supports the new tree format. |
58 |
|
59 |
This seems to me that we should come up with a tree format scheme such that |
60 |
when updating the tree, the package manager can then detect if it supports |
61 |
the updated tree's format or not. The upgrade case is then solved by the |
62 |
package manager refusing to fetch tree updates until the user upgrades the |
63 |
package manager to a version that supports the new tree format. The corner |
64 |
case here is where someone bumps the tree version but all available package |
65 |
managers are not yet in the tree. This would prevent users from upgrading |
66 |
to a version of their package manager that supports the new tree format |
67 |
because the ebuilds would no longer be available in the old format. |
68 |
|
69 |
An interesting solution to this would be to split the rsync data in to 2 |
70 |
trees, one 'old format tree' and one 'new format tree' and users can |
71 |
configure their clients appropriately. eventually the old format tree would |
72 |
be deprecated; tree changes would be replicated to both trees. |
73 |
|
74 |
Flame on |
75 |
|
76 |
-alec |