Re: Design Document: Version 0.01
Hi,
I'm taking the release early, release often methodology to
heart. The document is currently a plain text file, since it is going
to be refined over email, but I'll write it out in debiandoc sgml
later.
Also, the document is mostly outlines, so that I'm sure I've
not missed anything major. Several releases a day would not be
surprising; Jason has put a week's deadline on this so that we may
get upto speed on this.
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.
As the beatles said; Help!
manoj
--
As ceremony is the invention of wise men to keep fools at a distance,
so good breeding is an expedient to make fools and wise men equal.
-- Steele
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
The Deity project design document Version 0.01
=== ===== ======= ====== ======== ======= ====
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.
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. *Question: is this the same backing
store as above, with different flags?
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.
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) FTP methods
d) mount and file traversal module(s)?
e) Status file parser/generator.
f) available file parser/generator (related to above)
g) dependency/conflict determination and linking
h) reverse dependency generator. Maybe merged with above
i) package ordering/event generation module
f) module to interact with dpkg
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 |
|_________________| |___________|
dpkg also interacts with status and available files.
Reply to: