| 1 |
»Q« <boxcars@×××.net> wrote: |
| 2 |
> |
| 3 |
>> $ grep KEYWORDS /usr/portage/metadata/md5-cache/dev-perl/Pango-1.224.0-r1 |
| 4 |
>> KEYWORDS=~alpha ... |
| 5 |
>> |
| 6 |
>> $ grep KEYWORDS /usr/portage/dev-perl/Pango/Pango-1.224.0-r1.ebuild |
| 7 |
>> KEYWORDS="alpha ..." |
| 8 |
|
| 9 |
This seems to be a race issue in the gentoo infrastructure: |
| 10 |
Calculation of the metadata can need a long time. |
| 11 |
Apparently, this happens on the same directory into which |
| 12 |
fresh ebuilds are fetched so that the whole data can be |
| 13 |
inconsistent in some cases. |
| 14 |
|
| 15 |
Portage apparently verifies with a checksum whether metadata is up-to-date, |
| 16 |
and if not, it calculates the metadata locally, so it detects the race |
| 17 |
and "fixes" it locally. Eix does not use this mechanism by default, |
| 18 |
because checksumming for the whole tree slows down considerably, |
| 19 |
and execution of ebuilds (to calculate the metadata) is always |
| 20 |
very slow and a security risk: Note that in contrast to portage, |
| 21 |
eix has to do it for every ebuild in the tree (portage only does |
| 22 |
it on an as-needed basis). |
| 23 |
|
| 24 |
It should be possible to configure eix to behave this way, too |
| 25 |
(though I hardly ever tested it.) |
| 26 |
From memory, I guess that putting one of |
| 27 |
|
| 28 |
PORTDIR_CACHE_METHOD="parse#metadata-md5#assign" |
| 29 |
PORTDIR_CACHE_METHOD="parse|ebuild*#metadata-md5#assign" |
| 30 |
PORTDIR_CACHE_METHOD="ebuild*#metadata-md5" |
| 31 |
PORTDIR_CACHE_METHOD="ebuild#metadata-md5" |
| 32 |
|
| 33 |
in /etc/eixrc/ should do (ordered from |
| 34 |
fastest/still safe but not very reliable to |
| 35 |
slowest/least secure but completely reliable). |
| 36 |
(Maybe the appendix [the part after #] is autoamtic by |
| 37 |
CACHE_METHOD_PARSE; I do not recall in the moment whether |
| 38 |
CACHE_METHODS_PARSE applies to PORTDIR_CACHE_METHOD as well.) |
| 39 |
|
| 40 |
> I ran eix-sync again -- D'oh! I meant not to do that in case waiting |
| 41 |
> would help answer my question -- and now the KEYWORDS in |
| 42 |
> metadata/md5-cache/dev-perl/Pango-1.224.0-r1r1 matches the KEYWORDS in |
| 43 |
> the ebuild, and all is healed again. |
| 44 |
|
| 45 |
Yes, meanwhile the metadata generation on the gentoo infrastructure |
| 46 |
had probably been executed once more. It might be that the metadata for |
| 47 |
some other ebuild is then out of sync. |
| 48 |
|
| 49 |
> I would like to know how the metadata cache gets out of step with the |
| 50 |
> info in the ebuilds in the first place, how to prevent that |
| 51 |
|
| 52 |
Except generating the metadata by yourself there is not much you |
| 53 |
can do. |
| 54 |
Alterantively, file a bug to infra, 'though I am not sure whether |
| 55 |
they will consider it as a bug, since portage has means to linger |
| 56 |
the effect. |
Archives