plugin code plans

[Auke Kok]

Hi all,

Here's an outline on the current planned things I intend to code (and 
what has already changed) (some) regarding the plugin system I created in 
theedge:

1 - versioned modules are gone. Moonbase already had only one (gcc/3.4.3) 
and it would be better to replace or delete it

This was a requirement for:

2 - arbitrary path depth of modules in moonbase (finished). Modules can 
be in section 'gnome/apps', 'zlocal/personal/xfce4-cvs' etc. Note that 
this is analogous throughout the code, so the code really things that 
'my/dir' is a section, but 'my' also is (unless there is no module in 
'my'). Lvu section/moonbase etc. all work the same.

Modules are detecetd by their DETAILS files.

If we ever switch to subversion to maintain moonbase we can move stuff 
around wherever we want (x11/qt/kde/3 anyone? just kidding!)

3 - extension of the plugin system:

3a - making all core code that performs the same functionailty multiple 
times plugins (remaining candidates: bootloader handling, possibly 
xinetd, initd, pamd, gather_docs (all post_install handlers!))

3b - removing plugins that are finished into their proper module in the 
moonbase directory. Example: the download-subversion.plugin will go into 
moonbase/devel/subversion. That will allow us to install the plugin 
automatically once you lin subversion (or something that requires svn), 
and remove it automatically. Also, as discussed with goran Krampe, it 
will allow module writers to extend non-popular pieces of code without 
the need for core devs to merge obscure patches. The module author can 
push his plugin with a module

4 - aliases

In one week I will remove xservers-profile and replace it with the %X 
alias throughout moonbase.

as usual, this is all up for discussion etc. Note that the plugin code 
already is working in theedge, so go take a look in 'plugins.lunar' and 
the '/var/lib/lunar/plugins' directory as usual for examples.

5 - Easter

Happy easter everyone !!!

sofar