| 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 |
Archives