DPS Initial Ideas

[Thomas Sparrevohn]

On Sunday 13 May 2007 11:37:57 Peter Jeremy wrote:

> 
> The options I can see are:
> - Ignore the existence of INDEX - which makes computing dependencies
>   very time consuming
> - Fully rebuild INDEX via "make describe" whenever you update any ports
>   - this takes of the order of an hour
> - Find and rebuild the changed bits of INDEX - p5-FreeBSD-Portindex
>   uses this approach.
> - Build a tool that functionally does "make describe" but does it in
>   bulk much faster (eg by pre-parsing the include files once instead
>   of 17000 times).
> 


Having played around with using Postgres as a database for ports - I must
stress that its not a database vs. flatfile issue - It is quite easy to build a 
reasonable "Ports database" - however it does not help on the issue - namely
that dependencies and options means that it is needed to run make in order
to gurantee that the INDEX file are correct 

It seems to be a non-debate what format the database is in if there not a
good answer to how ensure that only ports that has changed are updated.

At the end of the day - "make based ports" are the only real safe way to manage 
ports - However the focus on the indexing side seems misplaced - example -
make INDEX on this host take 8-12 Minutes - compiling all ports installed takes
24 Hours - now if I "hand build" the dependencies structure and run the builds in
parallel it takes down to 4-5 Hours - so lets say we half the time it takes to
maintain the index - well - it cuts minimum time off the entire build process and
the effort and energy proberly better spend on trying to define a build sequence 
that allows ports to build with "make -j x" and with parallel builds where "-j n" 
does not work  

Using XML for INDEX are a very good idea mainly because it allows "ports"
to interface in an easy way to external tools - e.g. java frontends - 
web browsers etc, etc. However there are drawbacks - Yet I feel that the
discussion about what tool to use as indexing are completely misplaced 
if the only point is that somebody likes SQL better than a  directory tree.

> >Yes, and i don't buy the idea that using *existing* tools is better than
> >using the best tool for the job (assuming one can prove what is the best tool,
> >considering power, familiarity, etc.).
> 

Remind me - we are told that SQL are the answer but what was the question again?
 
> Demonstrate a better tool.
> 

Always the best way ;-)