| 1 |
2 other vdb size reductions can be done, with maybe a 3rd in the |
| 2 |
distant future. |
| 3 |
|
| 4 |
If you cat your /var/db/pkg/sys-devel/gcc*/IUSE you will notice that we |
| 5 |
have several inherited duplicates in it. To reduce wasted bytes there we |
| 6 |
can simply tr,sort,uniq them from bash. |
| 7 |
|
| 8 |
The for the vdb USE file I'm thinking we only need to save the USE flags |
| 9 |
that correspond to the IUSE flags when the package was merged. |
| 10 |
|
| 11 |
These smaller files should directly equate to portage speed ups when |
| 12 |
importing as it's less runtime reprocessing that has to be done. |
| 13 |
|
| 14 |
Anybody see any reason not to make the 2 above changes for .54 ? |
| 15 |
|
| 16 |
|
| 17 |
-- Maybe way future? -- |
| 18 |
We could take it a step further even and stop using a single file for |
| 19 |
just about every vdb entry excluding the env.bz2, CONTENTS and COUNTER |
| 20 |
and anything else that needs to be multiline. |
| 21 |
|
| 22 |
CFLAGS= |
| 23 |
RDEPEND= |
| 24 |
DEPEND= |
| 25 |
IUSE= |
| 26 |
USE= |
| 27 |
etc.. |
| 28 |
|
| 29 |
More or less treating it in pretty much the same manor as metadata cache |
| 30 |
entries. I see such a method as having mostly advantages and maybe 1 |
| 31 |
disadvantage. An initial 'import portage' could be slower unless |
| 32 |
PROVIDE,USE were the first two entries and the file was parsed and does |
| 33 |
not continue to read the rest of the file. ie no grabfile. |
| 34 |
|
| 35 |
-- |
| 36 |
Ned Ludd <solar@g.o> |
| 37 |
Gentoo Linux |
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-portage-dev@g.o mailing list |
Archives