Re: Design Document: Version 0.01
On 29 Sep 1997, Manoj Srivastava wrote:
> 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).
There is an extra field that points to a PackageFile structure for each
version. The structure contains the location, size and other data needed
to ensure it hasn't changed since the cache was build.
If you try to add two versions that are the same then one will be mostly
ignored (Some fields will be considered). This means the order that the
packages are combined should be the order of fastest->slowest mirror so
that slow mirrors will only be used if the fast ones do not have the
package. In this way you can point deity at a CDROM and ftp.debian.org and
any installs that can will come off your CD by default.
> Please look at version 0.02. If the top level points are OK,
> then we need to start expanding on each of the points.
I think they seem fine. New diagram (0.3) is okay too.
Though, how much detail should be in the diagram, IE there is another
important module, the Parser/Raw Store module. Ie there is an entire suite
of classes devoted to analysing elements of the package list. For instance
the backing store uses the pkgElmPkgList parser/store class to parse all
of the lists of package fields (depends, etc).
Unfortunatly the purpose these were designed to fill is less prominate
than before the cache, but they do have a role. When the user selects a
single package in the display we must go back to the package file to
extract the description and other non-cached fields. This is done using
the fulll set of Parser/Raw store classes -- ie you point the plaintext
parser at the file and it will instantiate a full suite of objects to
represent all elements in their most ideal form. (The cache has a byte
offset into the package file for each version btw)
> dpkg also interacts with status and available files. The user
> interface also hooks into the update module, but I can't draw that
> here.
I don't think dpkg uses the avail file, only dselect does (?) no
information in it that dpkg should need at least. Ideally dpkg would use
the backing store.. maybe in future?
Jason
Reply to: