Dependencies, their tracking and what we need to improve.

[Zbigniew Luszpinski]

> There are still some open questions that need additional discussion or
> clarification about Lunar's dependency system. In the past there has
> been some talk about switching the dependency tracking to a database
> and Jean has done some work using sqlite.
> 
> With the help of Ratler it is now in a usable shape as for its speed.
> There are a few things left such as tying it into lin, lvu, etc and
> what should be done as a fall back should the database become
> completely hosed.
> 
> Before that happens (if it does) there has been mixed opinions about
> dependencies. Specifically;
> 
> 1. those of the optional variety
> 2. how explicit the DEPENDS should be
> 3. and how far down the tree should a `lrm -p $MODULE` should go
> 4. do we really need to switch to a database or provide a user with a
> choice of database or current method
> 
> Point 1 - Auke has stated he does not like seeing an optional_depends
> without an accompanying on/off switch. I can understand that because
> the optional_depends without it could cause the module to fail
> requiring the user to lrm the offender and then later on reinstall it.
> 
> But the problem is this; there are many modules with their configure and
> cmake scripts that have no corresponding on/off switch. For example;
> kdelibs4 has no way to enable/disable grantlee even though it can be
> used during its build. So what is an acceptable method of handling
> these types of optional_depends?
> 
> Point 2 - This has some bearing on Point 1 in that to make a modules
> DEPENDS more explicit we run into those that have no corresponding
> on/off switch. The second part to this point is; how far down the tree
> should we go to have a comprehensive dependency tracking system?
> 
> Point 3 - As it stands now and I have not tried this in a very long time
> because it broke my box; at what point do we halt a `lrm -p $MODULE`?
> Even with a ultra-mega super-duper tracking system this would still be
> of concern.
> 
> Point 4 - I am amiable to the idea if only from the point that it
> could/would speed up the sorting which right now is not so great. Just
> so that we have it documented, please itemize what a database
> dependency tracking system would provide and potentially change how a
> DEPENDS is currently constructed.
> 
> If we are going to move forward to improve the dependency tracking I
> feel there needs to be additional inputs. If the work Jean has done is
> the direction to head it will need testing on multiple boxes by
> multiple users (devs). I have no problem being part of that but given
> the scope the more the merrier.
> 
> Side note; Would it be preferable to setup an IRC meeting to discuss
> this or is everyone fine with the mail list?

One more thing.  Two options in lunar menu would be useful for depends:
[X] If module installed use it as optional depends without asking
[X] If module not installed do not ask to install it as optional depends

have a nice day,
Zbigniew Luszpinski