Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Google SoC and "cache sync"
Date: Thu, 02 Apr 2009 05:39:03
In Reply to: Re: [gentoo-portage-dev] Google SoC and "cache sync" by Zac Medico
2 Hash: SHA1
4 Zac Medico wrote:
5 > Emma Strubell wrote:
6 >> And to clarify: the goal of the project is to modify portage so that
7 >> instead of fetching all of the ebuilds in the portage tree (or in an
8 >> overlay) upon a sync, portage only fetches the metadata and cache info
9 >> (via the metadata/cache/ directory) of the tree, and the ebuilds of
10 >> packages that are already installed (packages found in the world
11 >> file?) And then, additional ebuilds would be fetched only when they
12 >> are needed?
13 >
14 > The problem with fetching the ebuilds separately is that the remote
15 > repository might have changed. So, it's not a very reliable approach
16 > unless there is some kind of guarantee that the remote repository
17 > will provide a window of time during which older ebuilds that have
18 > already been removed from the main tree can still be downloaded. In
19 > order to accomplish this, you'd essentially have to devise a new
20 > source package format which can be downloaded as a single file
21 > (something like a source rpm file that an rpm based distro would
22 > provide).
24 Expanding on this a bit... if you were going to pack an ebuild into
25 a single file, you would need to include the eclasses which it
26 inherits and also any patches that are included with it in cvs. If
27 the eclasses are included in this way, each source package will
28 contain a redundant copy of the inherited eclasses. Despite this
29 redundancy, you might still have a net decrease in bandwidth usage
30 since you'd only have to download the source packages that you
31 actually want to build.
33 If you are going to implement something like this, I imagine that
34 you'd create a tool which would pack an ebuild into a source package
35 and optionally sign it with a digital signature. Source packages
36 would be uploaded to a server which would serve them along with a
37 metadata cache file that clients would download for use in
38 dependency calculations (similar to how $PKGDIR/Packages is
39 currently used for binary packages).
40 - --
41 Thanks,
42 Zac
44 Version: GnuPG v2.0.11 (GNU/Linux)
46 iEYEARECAAYFAknUT0oACgkQ/ejvha5XGaPmugCfVs0I4a15trwTgLnPwBac2xOj
47 wI0AoInp1Jf6yaYV5rNvU2EXHbZ30AkS
48 =tNrz
49 -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-portage-dev] Google SoC and "cache sync" Emma Strubell <emma.strubell@×××××.com>