1 |
gentoo-server is probably not the best list for this discussion, but I |
2 |
suspect many or most of the people on it will have an interest in |
3 |
this, so it is somewhat-on-topic. If there's any interest/traction, |
4 |
then I'll redo this as a GLEP. If you like the idea but think it |
5 |
should be discussed off this list, contact me directly. |
6 |
|
7 |
There are two main issues with the Portage tree as I see it: |
8 |
|
9 |
1) There's no way to get just security updates. |
10 |
|
11 |
2) Even with recent metadata cache update improvements, it still takes |
12 |
a long time, and a lot of resources, to sync the tree. |
13 |
|
14 |
Now while I firmly believe Gentoo has the best build system and |
15 |
packagement management bar none, I think there are still a few good |
16 |
ideas out there in other systems to be borrowed/stolen. |
17 |
|
18 |
Currently, emerge --sync (typically) does an rsync off one of the |
19 |
Gentoo rsync mirrors and then updates the metadata cache. This process |
20 |
involves examining every file in the Portage tree on both sides of the |
21 |
connection (stat). This is fixed overhead which is linearly |
22 |
proportional to the number of files in the tree, regardless of how |
23 |
many actual updates there may be. Fortunatelly, there is an |
24 |
optimization that checks a specific timestamp file on the mirror and |
25 |
skips the real sync if it matches the local timestamp. |
26 |
|
27 |
Compare this with the Debian/Ubuntu method (I'll follow Ubuntu's |
28 |
conventions, since I'm more familiar with it): Each time there is is a |
29 |
new release, you get a new dist, plus dist-updates, and dist-security, |
30 |
and a couple others I'll ignore for now. For example, Ubuntu's current |
31 |
release is dapper, so there is also dapper-updates and |
32 |
dapper-security. |
33 |
|
34 |
Now the beauty of this is that once a release is actually final, the |
35 |
main release files (i.e. dapper) *do not change*; any updated package |
36 |
specs go into the -updates or -security directories. If most of the |
37 |
packages do not change during the update life of a distribution, i.e. |
38 |
updates are a relatively small percentage, then this is a big win. |
39 |
(AFAIK, apt-get and other methods check remote timestamps before |
40 |
downloading.) |
41 |
|
42 |
How can this idea be applied to Portage? In this sort of scheme, you'd |
43 |
have something analogous to an apt.sources line in Debian in profile's |
44 |
make.defaults: |
45 |
|
46 |
SYNC="rsync://rsync.gentoo.org/gentoo-releases" |
47 |
RELEASE="2006.1" |
48 |
RELEASE_OVERLAYS="updates security" |
49 |
|
50 |
Doing a emerge --sync would then perform the following: |
51 |
|
52 |
* rsync://rsync.gentoo.org/gentoo-releases/2006.1 to $PORTDIR |
53 |
* rsync://rsync.gentoo.org/gentoo-releases/2006.1-updates to $PORTDIR-updates |
54 |
* rsync://rsync.gentoo.org/gentoo-releases/2006.1-security to $PORTDIR-security |
55 |
|
56 |
$PORTDIR-updates and $PORTDIR-security could then be treated as |
57 |
implicit PORTDIR_OVERLAYs. SYNC could be overridden in /etc/make.conf |
58 |
as it is now. If you wanted only security updates, then you could set |
59 |
RELEASE_OVERLAYS="security" in make.conf. |
60 |
|
61 |
This is now three trees to sync against instead of one, but the |
62 |
important feature is that the primary tree is now static data, once it |
63 |
is done as a final release, so there is only the timestamp check; and |
64 |
the other two trees should be relatively small. Obsolete ebuilds need |
65 |
only be removed when there is a new release, and this happens in a |
66 |
different tree. Potentially, only packages with at least one stable |
67 |
arch flag could go in updates; anything that is all ~arch or masked |
68 |
could go into a separate testing overlay. |
69 |
|
70 |
Known Issues: |
71 |
|
72 |
* Gentoo infrastructure changes are going to be required, particularly |
73 |
in the mirror system and repoman and the Portage CVS tree. However, it |
74 |
should not require major surgery on Portage/emerge. |
75 |
|
76 |
* End-users will have to change their configuration a bit, or at least |
77 |
SYNC. Note that I changed the SYNC location from gentoo-portage to |
78 |
gentoo-releases, since releases would need to be rooted outside the |
79 |
existing tree (resulting disaster left as an exercise for the reader). |
80 |
The existing tree may still be useful to keep for developers, testers, |
81 |
and good old backwards-compatibility (set RELEASE=""). |
82 |
|
83 |
-- |
84 |
This message has been scanned for memes and |
85 |
dangerous content by MindScanner, and is |
86 |
believed to be unclean. |
87 |
-- |
88 |
gentoo-server@g.o mailing list |