Re: Design Document: Version 0.01
Hi,
>>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
Jason> Take out the Availble file and replace it with something like
Jason> Package file directory. Status file is singlular too.
OK. How do we keep track of the original location of a
package (extra field for each package)? How do we handle different
package files having different versions of the same package? (There
is nothing preventing me from using two mirrors to ensure my machine
is the most cutting edge).
Jason> That is basically the current design, I think the configuration
Jason> module will also tie into the UI. The backing store (cache) is
Jason> the central data structure.
Right. I think we should separate the configuration module
from the update module. I'm re-drawing the diagram
Jason> There should be an extra layer between the ordering module and
Jason> dpkg, the package manager invoker thingy (what ever that will
Jason> be)
Fine. (I like that; the pure ordering module can thus be made
more generic)
Jason> Why is the configuration module on the other side of
Jason> configuration data? Shouldn't thinkgs interact with the module,
Jason> not directly with the data?
Right. I redrew the diagram.
Please look at version 0.02. If the top level points are OK,
then we need to start expanding on each of the points.
Manoj
--
``Once again, we see that interesting correlation between saying
"Blessed Be!" and being an idiot.'' Gene W. Smith,
gsmith@garnet.berkeley.edu
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
The Deity project design document Version 0.02
=== ===== ======= ====== ======== ======= ====
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|
| module |<=>| data | |______________|
|______________| |_____________| ^
^ |
| _______v_______
| ______________ | | ________________
| |Status file |/___\| |/_\| Dependency |
| |______________|\ /|backing store |\ /| Module |
| |______________| _|_______________|
| ^ /| ^
| | / |
| ______v_______|/__ ______v____
|_____________________________\| User interaction| | dpkg |
/|_________________| | Invoker |
|___________|
dpkg also interacts with status and available files. The user
interface also hooks into the update module, but I can't draw that
here.
Reply to: