Re: Design Document: Version 0.01
On 29 Sep 1997, Manoj Srivastava wrote:
> I need your help, since I am a johnny-come-lately with little
> experience with Deity yet, so there are likely to be major errors and
> omissions.
Looks pretty good so far actually :>
> c) Local status: Build up a list of packages already installed. Use
> a backing store for speed. *Question: is this the same backing
> store as above, with different flags?
Yes, the backing store (cache) contains all package files. Diety will not
use the availble file, but a directory of package files for different
sources. All of them are combined along with the status file to produce
the final data structure that contains all information about all packages
in all availble sources.
> d) Determine forward and reverse dependencies. Update the backing
> store with this information. *Note* Should we track recommends
> and suggests as well? I think so.
As implemented now it does track recommends and suggests, it tracks all
forms of package lists (Predepends, conflicts, replaces, depends,
suggests, recommends) because it's cheap and simple to do.
> 4. Data flow and conversions analysis.
> ____________
> __\|ftp modules|
> / /|___________|
> ______________ _ ____________ / ________________
> |Configuration | |configuration| / |mount/local file|
> | module |<=>| data |/_____\| traversals |
> |______________| |_____________|\ /|________________|
> ^
> |
> _____v________
> |Available file|
> |______________|
> ^
> |
> _______v_______
> ______________ | | ________________
> |Status files |/_____________________\| |__\|Ordering module |
> |______________|\ /|backing store | /|Event generator |
> |______________| |________________|
> ^ ^
> | |
> ______v__________ ______v____
> | User interaction| | dpkg |
> |_________________| |___________|
Take out the Availble file and replace it with something like Package file
directory. Status file is singlular too.
That is basically the current design, I think the configuration module
will also tie into the UI. The backing store (cache) is the central data
structure.
There should be an extra layer between the ordering module and dpkg, the
package manager invoker thingy (what ever that will be)
Why is the configuration module on the other side of configuration data?
Shouldn't thinkgs interact with the module, not directly with the data?
Jason
Reply to: