From: Kenneth J. D. <je...@co...> - 2001-10-24 22:20:57
|
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... |