Re: Design Document: Version 0.01
Hi,
Ok, the extra field that points to a PackageFile structure
takes care of identifying the source.
If a package file contains foo version 2, and another package
file contains foo version 3, and foo version 1 is installed, then
irrespective of the order of reading package files I should get foo
upgraded from version 1 to version 3. This is not likely to happen
often, so invoking the version camparison routine should not slow
things down much.
Even though the Parser/Raw Store module is not mentioned in
the diagram, it should be mentioned in the modules list (Section 3),
and the textual description of the diagram it self (I think I have
nearly reached my level of creativity with ascii graphics). I think
pkgElmPkgList parser/store class should be mentioned in the design
document of the backing store module; when we get that far.
At the moment I think we should define the external entry
points for all the modules identified. This would allow us to develop
the modules separately; as long as the API is respected, it does not
matter what is inside any module. The API's should further help
clarify the data flow model, and vice versa.
I'll change the bit about dpkg using the avail file, and try
to flesh out the requirements a bit tomorrow.
manoj
--
A lot of the stuff I do is so minimal, and it's designed to be
minimal. The smallness of it is what's attractive. It's weird,
'cause it's so intellectually lame. It's hard to see me doing that
for the rest of my life. But at the same time, it's what I do
best. Chris Elliot, writer and performer on "Late Night with David
Letterman"
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
Reply to: