From: Aitor Santamaria Merino <ait...@wa...>
>My first naive approach would be something like adding a list of
>packages that are required, and a minimum version. If the version field
>is standarized (e.g. BYTE.BYTE.BYTE), then one can define version
>comparing routines, so that one could also include list of dependencies:
>
>[Dependencies]
>ThisPackage=1.0.0
>AnotherOne=4.1.2
>
>This way, if AnotherPackage ver. 4.1.7 is already installed, then the
>checking will succeed, and if ThisPackage doesn't exist, or version is
>previous to 1.0.0, then it should be asked this package to be installed.
I will update FDP version 0.2.0 to include dependency support, and update
the libraries to at least handle the dependency data (ie ignore it).
Later I (or someone else) can add the logic to take advantage of the
included dependency information.
I don't intend to increase the FDP version # as the previous message
was only sent to this list, and it indicates that was the proposed version.
Basically this is what FDP 0.2.0 will look like:
information/fdp version header
current general package header BYTE name[] .. DWORD count
DWORD dependcnt /* how many packages we are dependant on */
0 or more dependency records, dependcnt specifies how many
0 or more file records, count specifies how many
Dependency Record
WORD[3] minversion (the minimal major.minor.patch version of
package that we need installed prior to this one)
WORD[3] maxversion (usually zeroed or FFFFh.FFFFh.FFFFh, contains the
highest version of a package that will work and that
we need installed prior to this one - this
is used only if you know in advance (package
creation time) that a given version and above
breaks compatibility that is needed with this package.
BYTE[ML_NAME] pkgname The name of the package that this package is
dependent on, pkgname should be '\0' padded and
in the same form as the package name used in the
general package header.
Jeremy Davis
je...@co...
|
