Re: Design Document: Version 0.01
Hi,
Sorry for the flood, but I redrew the diagram, I thik we are
getting close. Here comes version 0.03.
manoj
--
The fancy is indeed no other than a mode of memory emancipated from
the order of space and time. -- Samuel Taylor Coleridge
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
The Deity project design document Version 0.03
=== ===== ======= ====== ======== ======= ====
0. Introduction
Deity is supposed to be a replacement for dselect, and not a
replacement for dpkg. However, since addition functionality has been
required for deity, and given the fact that this is very closely
related to dpkg, it is not unreasonable to expect that additional
functionality in the underlying dpkg would also be requested.
1. Requirements
a) Deity should be a replacement for dselect.
b) it should be easier to use and less confusing for novice users.
c) It should be able to group packages more flexibly, and possibly
allow operations based on a group
d) Make use of a keywords field in package headers; provide a
standard list of keywords for people to use.
e) use dependencies, conflicts, and reverse dependencies to properly
order packages for installation and removal
f) handle replacement of a package providing a virtual package with
another (replacing sendmail with smail), making sure that the
dependencies are still satisfied.
g) handle source lists for updates from multiple sources (main,
contrib, non-us, non-local, non-free, my-very-own)
h) handle base of source and acquire all Packages files underneath.
(possibly select based on architecture)
i) handle remote installation (to be implemented maybe in a future
version). Still needs to be designed.
j) Be scalable (dselect worked a lot better with 400 packages)
k) handle install immediately requests
l) handle predependencies.
m) Handle "standard installations". Define a few standard
installations, and which packages are included therein.
2. Procedural description
a) Set Options: configuration. source list details, etc
b) Updates: build a list of available packages, using source lists
of a base location and trawling for Packages files (needs to be
aware of architecture). Use a backing store for speed.
c) Local status: Build up a list of packages already installed. Use
a backing store for speed.
d) Determine forward and reverse dependencies. Update the backing
store with this information.
e) Selection: Present the data to the user. Look at Behan Webster's
documentation for the user interface procedures.
f) Installation/configuration etc.
Build a list of events. Simple topological sorting gives order of
packages in dependency order. At certain points in this ordering,
predependencies/immediate configure directives cause an break in
normal ordering. We need to insert the uninstall/purge directive
in the stream (default: as early as possible)
g) Execute the list of events if succesful. Do not partially install
packages and leave system in broken state. Go to step 2e as
needed.
3. Modules and interfaces
a) The user interface module: Look at Behan Webster's documentation.
b) widget set, related closely to above
c) Update Module
i) FTP methods
ii) mount and file traversal module(s)?
iii) Other methods ???
d) Status file parser/generator.
e) Package file parser/generator (related to above). Handle multiple
Packages files, from different sources. Need an extra field to
keep track of the initial location for each package?
f) Dependency module
i) dependency/conflict determination and linking
ii) reverse dependency generator. Maybe merged with above
iii) package ordering/event generation module
g) module to interact with dpkg
4. Data flow and conversions analysis.
____________
__\|ftp modules|
/ /|___________|
_ ____________ / ________________
| update | / |mount/local file|
|==========================>| module |/_____\| traversals |
| |_____________| /|________________|
| ^ ^
| | | ______________
______|_______ _ _____ ______ | _____v________ \| |
|Configuration | |configuration| | |Packages Files| ===|Status file |
| module |<=>| data | | |______________| / /|____________|
|______________| |_____________| | ^ /
^ | | /
| | _______v_______|/_
| | | | ________________
| | | |/_\| Dependency |
| | |backing store |\ /| Module |
| | |______________| _|_______________|
| \ ^ /| ^
| \ | / |
| _\|____v_______|/__ ____v_______
|_____________________________\| User interaction| | dpkg |
/|_________________|<==>| Invoker |
|___________|
dpkg also interacts with status and available files.
Reply to: