For the fun of it, I created a little tool very custom and untested that will 
read the the cache files of gentoo and generate on the stdout a valid xml 
file.

Now the schema/dtd has been created without any thinking.  This may or not 
open the door to people to experiment with a gentoo equivalent database.

What's interesting is that the database is generated from a gentoo system 
pretty easily because of the presence of the cache.  One could easily think 
about creating a direct ebuilds -> xml db software instead of passing through 
the cache.

Discussion with carspaski reveal thought that the use of the database will 
actually not speed up emerge.  Because emerge loads the cache inside an 
internal memory database and python allow him to leave that in memory in 
between runs making it very fast and efficient as only the require entry of 
the database gets loaded instead of the whole database.

Some benefit I see from the xml db is for side-tools, for example search 
description of ebuilds is faster when using xml db as it is a single file and 
software only look for string that start with <description>.  One can use 
grep/regexp to do such query or built an xml capable application.

I believe that more works need to be put into this to figure out a better dtd 
and a separation of elements that would make more sense to some of the 
application such as kportage and others gui tools that try to load all at 
startup due to lack of persistent daemon keeping stuff in memory.

test.sh is the bash script that start the xml output and then do a recursive 
ls of /var/cache/edb/dep.  Then for each file it calls xmltest which is a 
libxml2 app that will only convert the read text in ISO-8859-1 and then 
output with escaping special chars as defined in XML 1.0.

I'm including only the source. I use the following compile line:

gcc -I /usr/include/libxml2 -o xmltest xmltest.c -lxml2

To run, 

./test.sh > gentoo.xml

It generate a 9525071 bytes file.

-- 

Yannick Koehler
 

--
gentoo-dev <at> gentoo.org mailing list