| 1 |
> I'm wondering where I can find some doc about portage, and especially |
| 2 |
> the cache part. I use debian at work, and get so sad when doing an |
| 3 |
> emerge rsync at home (10 or 15 minutes to rsync, and almost 5 minutes to |
| 4 |
> calculate world dependancies) on a bi-athlon 1.8GHz. |
| 5 |
|
| 6 |
This can be highly dependent on portage version. If you are using |
| 7 |
2.0.51, there is no cache available on the servers as of yet. The |
| 8 |
format has changed. |
| 9 |
|
| 10 |
Using 2.0.51, with an EMPTY cache the performace should still |
| 11 |
be greater than what you are stating. It takes me 2m59.628 on |
| 12 |
my P4-2.2 Laptop (5400 RPM) to 'emerge -puD world'. If you're |
| 13 |
seeing 5 minutes, there may be an issue on your system with IO. |
| 14 |
|
| 15 |
After caching, it takes 7.867 seconds on my laptop. |
| 16 |
|
| 17 |
2.0.50 should be fairly similar to the rates of 2.0.51 with |
| 18 |
a populated cache. The generation times can vary. A hidden |
| 19 |
feature, 'the modules file', might help as well. |
| 20 |
|
| 21 |
carpaski@fenchurch carpaski $ cat /etc/portage/modules |
| 22 |
portdbapi.auxdbmodule="portage_db_anydbm.database" |
| 23 |
eclass_cache.dbmodule="portage_db_anydbm.database" |
| 24 |
|
| 25 |
You'll have to sync after you make those changes as the cache |
| 26 |
is essentially invalidated/not-present. |
| 27 |
|
| 28 |
> maybe ebuilds should be "compiled" into seriaziled objects |
| 29 |
> or something similar. Only an emerge rsync (or something |
| 30 |
> called "emerge update") would fetch new ebuilds, and compile |
| 31 |
> new ones (we don't care anymore of hand modified files after sync). |
| 32 |
|
| 33 |
There are a lot of things you could take for granted with the |
| 34 |
cache. There are problems inherent with assumptions though; they |
| 35 |
tend to break things. Portage forces a complete update of the |
| 36 |
cache to ensure that nothing strange happens. The cache entries |
| 37 |
_CAN_ and _DO_ change randomly sometimes. Fixing a portage bug |
| 38 |
here and there might cause a variable to change and without the |
| 39 |
regeneration you wouldn't see that. We've had a lot of issues in |
| 40 |
the past where data in the tree was corrupt and/or wrong. This |
| 41 |
way expends a couple more minutes on the user's part and can free |
| 42 |
up many more on our dev's part. |
| 43 |
|
| 44 |
> I don't think it would be really difficult to implement a server that |
| 45 |
> would handle requests like : |
| 46 |
|
| 47 |
You would have to implement it. The problem is available time and |
| 48 |
interfacing with existing systems. If it's not as easy, efficient, |
| 49 |
and solid it's not readily acceptable. |
| 50 |
|
| 51 |
> Moreover, do I REALLY need all ebuilds content ???? Why can't portage |
| 52 |
> just look at some headers (with arch, desc, etc.) and left the install |
| 53 |
> part on other files. Rsync local tree would be lighter, and faster to |
| 54 |
> sync. When you need to emerge some program, emerge would download the |
| 55 |
> _real_ ebuild file, the digests, the distfiles, etc. |
| 56 |
|
| 57 |
It wouldn't be any faster. Rsync uses stat values to do the transfer |
| 58 |
determination. The values would be exactly the same for headers-only. |
| 59 |
|
| 60 |
--NJ |
Archives