Re: Design Document: Version 0.01
On 30 Sep 1997, Manoj Srivastava wrote:
> 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.
That is all up to the UI. Upgrading is done selectively based on what
distribution (stable/unstable) and user choice in that matter. The cache
can store N versions of the same package, each with distinct depends,
provides, etc. As part of the cache generation all version lists are
sorted (no duplicates are permitted) which means the only time versions
are compared is when depends are being analysed.
> 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.
Classes, there are ones for MD5, integers, multiline descriptions, conf
list, versions etc.
> 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.
Okay.
Jason
k
Reply to: