Dependencies, their tracking and what we need to improve.

[Dennis Veatch]

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?

-- 
Dennis `stumbles` Veatch
Lunar Linux Developer
http://www.lunar-linux.org/