handling circular dependencies

[wookietreiber]

Hello again,

some thoughts on BUILD ORDER or: which came first -- the egg or the chicken? 

... with modules it's not that complicated -- take 'cairo' and 'libspectre' as an example:

'libspectre' is an optional dependency of 'cairo' (to enable PostScript testing functionality)
'cairo' instead is a required dependency of 'libspectre'

So, if one wanted to 'lin cairo' with opt_dep 'libspectre' enabled, the build order would be obvious:
1. cairo      (without libspectre)
2. libspectre (with    cairo)
3. cairo      (with    libspectre)

The structure of 'optional_depends' is:
optional_depends "MOD" "YES_OPTS" "NO_OPTS" "DESCRIPTION"

The 1st build ('cairo') has to use NO_OPTS -- the system currently can't provide MOD, so it should use NO_OPTS to not let the build fail.
The 2nd build ('libspectre') can now be built since 'cairo' is available.
The 3rd build ('cairo' again) can now use MOD and has to use YES_OPTS to enable the functionality provided by MOD.


Same goes for cases where both modules are optional dependencies of each other, e.g. 'cairo' and 'poppler'

build order for 'lin cairo':
1. cairo   (without poppler)
2. poppler (with    cairo)
3. cairo   (with    poppler)

build order for 'lin poppler':
1. poppler (without cairo)
2. cairo   (with    poppler)
3. poppler (with    cairo)


Please correct me, if I'm wrong, but I don't guess there are cases, where both modules are required dependencies of each other. In case there are, my proposed solution would be to add an additional PRECOMPILED_SOURCE in DETAILS, which is a precompiled version to put in /tmp/ to enable some kind of bootstrapping.


Thanks for reading :) whoever made it this far :)

Best regards
Christian Krause aka wookietreiber



On Sat, Jan 15, 2011 at 10:18:04PM +0100, wookietreiber wrote:
> Hello,
> 
> revising the configuration of 'cairo' and much around it (take a look at the module submission queue) I discovered some circular dependencies ('libspectre', 'poppler' and 'librsvg' should actually be optional dependencies for 'cairo') and how troublesome and annoying they can be ... for now I handled them with POST_INSTALL and POST_REMOVE, which, of course, isn't the most elegant way to do this ...
> 
> ... so, what about a new function (e.g. called 'circ_depends') for '/var/lib/lunar/functions/depends.lunar' or, which would be even better, a revision of 'depends' and 'optional_depends', to handle circular dependencies directly in the lunar tools?
> 
> Generally, I don't know if it's just 'lvu tree module_with_circ_dep' breaking by going in an infinite loop or if it concerns other lunar tools as well -- I'm just not deep enough in it yet, but intend to :)
> 
> The intention of this mail is to encourage us to provide thoughts on what to consider to implement good circular dependency handling functionality and eventually, well, implement it :)
> 
> Best Regards
> Christian Krause aka wookietreiber
> 
> P.S.:   I'll start with some thoughts soon :)
> P.S.S.: Maybe someone knows other functions like 'lvu tree ...' which fail and post it to this thread -- this would help to find everything that breaks or may break.