Firstly, I believe that the solution to many of the build-depends, multi-threading, etc issues revolves around a simplistic reference engine. Each package maintains a list of references with reference types (For example: bar-2.6.5 = ["foo-2.3.4-2", "Required"],["USER","Requested"]) Then only when all references are destroyed is the package removed. Similarly, it could use the same list for opposing references, depending on the state of the install flag.
This complex information would be efficiently stored in a dbm type file (Along with some of the other package meta-data, the install instructions could be reread from the file when needed, for efficiency) with one entry per package-version-revision combo (The true package name).
There would also be a very small hash of {pseudo-name,version/revision} => array of {real-name-version-revision} stored in the "##PROVIDES##" record, or something like that. Its purpose would be to translate from requested name-version-revision to possible name-version-revision efficiently. I have some working code that allows dpkg-type version-revision combos and various sets and ranges of them to be manipulated (union, intersection, etc) efficiently (Still needs cleaning. I will make it available on my return in 3 weeks).
Secondly, I believe that the package manager should be abstracted from the packages. This would make adding new unusual (macosx, darwin, etc) packages easier. Basically, it would take the form of a .so loader, designed to load a "Package type" and query it for a list of packages.
I think that each package type should have the method enumerate_packages that returns a list of all packages available in that package type (NSArray of FinchPackage subclasses?). Then each subclass would implement a set of functions that define its behavior:
addRef/delRef - Modifies the reference array of the object. There would be default implementations of these that call install/remove/etc at the appropriate times. These are only necessary if one wants to make a package that cannot be installed or removed, etc (Like the macosx/darwin packages).
install/remove/etc - Actually modify the package. These should only be called by the default addRef/delRef implementations. If the ref methods are not overridden, then these must be.
We might start with an .info package type, and probably a "Obj-C .so" package type. The .info type would look in the existing /sw/fink fs tree for info files, cache the important stuff, and return a list. The "Obj-C .so" type would load a package from another shared object file, and hook up callbacks to an object. That could be used to find Mac OS X/Darwin/etc versions. We would probably add a .pl package type that would load callbacks from a perl script, and a "C .so" type that would use purely C callbacks. Then later on, if we decided to change our info format, we would only need to write a new module for it that checks in the same or a different place.
Please, any comments at all! I will be gone for 3 weeks, so please continue the discussion without me. I hope I have made my idea clear enough. Thank you all. When I get back I will clean up what I wrote, add in your suggestions, comments, etc, and release it for your comments.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a16 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP? t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
