depends rework thoughts.

[elaine]

On Mon, 8 Dec 2003 22:37:38 -0500
Steven Michalske <hardkrash at lunar-linux.org> did inscribe thusly:

> Hey team,
> 
> With christmas break comming up i decided what my winter project will be.
> 
> Start working on an improved depends system.

Hardkrash et al,

These are good ideas, but. I want to review the path that lies behind us 
before addressing the path that lies ahead. Because sofar and xoritor did
most of this work I may be missing some details, the gist, however I think
is correct.

Lunar (sgl) used to do full recursion in bash, This resulted in a (very) 
large number of subshells being spawned, and the resultant need for upwards
of a gig of VM to build gnome, kde, etc.

Sofar made the core depends system more efficient and added several data
files to support that. Therefor dependencies are cached after being solved,
and dependencies already 'resolved' aren't re-computed.

This was excellent work and has made it feasible to run lunar on lower
clock/RAM spec sysgtems. However,

There was a large proliferation of shell variables to accomplish this
and the data files sometimes get out of sync, causing problems that are
hard to debug / fix.



I am basically unwilling to develop/support additional features in bash.

As I think you all know, several months ago I wrote a dependency solver
in perl which does run full recursion, reads the current dependency tree 
and can backend to any sql database, or a berkely db file and solves 
dependencies faster than bash can, even though it's runnning full 
recursion.

That first pass of a perl based sover successfully plugged into the 'renew' 
function of lunar, however it only handled non-optional dependencies.

Since that time I have re-written it to handle optional depends (and it
was this exercise where I found that bash code embedded in the DEPENDS
file rendered dependencies *much* harder to translate). I now have a
version which can handle optional depends and the translation of the 
existing moonbase DEPS is at least nearly correct if not perfect.

This solver is guaranteed to give best build ordering, and gives different
order of build than the current core (even after sofar did a fix aimed
at improving build ordering.


I'm going to save the other reasons that I prefer not to add any significant
features to core in bash for a second email.


elaine