I think this proposal is coming too close to "reimplementing a database in a filesystem." The point of using the filesystem should be to *avoid* having a special central construct just for tracking dependencies (or whatever). Ideally, there should just be one method of storing the dependencies for each program, and it should lend itself to whatever purpose we need it to serve.
The /System/Links hierarchy is not a "central" database because it simply helps find the scattered files of the appropriate type efficiently. The structure itself doesn't add any additional semantics... all information is contained within the /Programs entries. In this proposal for dependencies, the information seems to be contained within the central structure. This means there are two pieces that need to be held in sync by the system scripts, rather than the folders in /S/L/* simply being collections of /Programs/*/*/* entries. >From a simplicity standpoint, I like Carlo's suggestion of a fancy grep over /Programs/*/*/Resources/Dependencies, with the possible optimization of linking the dependency files into /S/L/Dependencies and grepping that folder instead. However, the elegance and user-friendliness of checking what depends on each version of LibA by issuing `ls /System/Links/Dependecies/LibA/*` got me thinking about ways to get the advantages of that by leveraging existing concepts (and without adding significant complexity to the Scripts, which would make it harder to administer by hand). If each program's dependencies are stored as folders within its /Programs tree entry, they can be symlinked together in exactly the same way as the lib/ directories get symlinked together to form /S/L/L. Having zero-size files like this... /Programs/ProgramB/1.1/Resources/Dependencies/LibA/>=3.0/ProgramB--1.1 ...and symlinking /P/*/*/Dependencies into /S/L/Dependenices generates the hierarchy Anshuman suggested without requiring any additional complexity in SymlinkProgram. This could potentially replace the Dependencies file, since it stores the same information in the same place but in a way that's much more convenient for reverse lookup and not much harder to create or change manually. (If the current Dependencies file is kept, the folder name would of course have to be different than 'Dependencies' to avoid the conflict.) Like Anshuman's original proposal, this avoids the "order of installation" problem by not putting files into other programs' /Programs entries, and it avoids the performance hit of system-wide dependency scan. In addition, assuming this is used instead of Dependency files, it avoid the unnecessary duplication of information that I didn't like about the earlier proposals. Even if the original flat dependency files are kept, duplicating that information within each /Programs/*/*/Resources directory seems cleaner and more maintainable than any standalone central information repository or putting it into other /Programs entries. I don't have a particular need to be performing reverse dependency lookups often enough to need anything faster than Carlo's grep, but if something is implemented for RemoveProgram's use, I'd like to see it look like the above. -Andy On 7/2/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote: > similar, but 'gobo' is in the details :)... > If you have the rev links in a subfolder...if the folder is deleted > then the reverse dependencies are lost...the right place is > /System/Links...which can be backed up as needed > > The primary concerns in that response are to do with 'maintaining' the > links up to date [...] > Here is a sample based on the lib example given earlier: > > >/ For example if we have four versions of libA, > />/ > />/ libA/1.0 > />/ libA/2.0 > />/ libA/3.0 > />/ libA/4.0 > />/ > />/ then install programB/1.1 which depends on libA >= 2.0 and libA <= 3.0, > />/ programB will be symlinked to/ > > /System/Links/Dependency/ > libA/ > <=3.0/ > > programB-1.1 -> /Programs/programB/1.1 > >=2.0/ > > programB-1.1 -> /Programs/programB/1.1 > > Note: creating these links does not need the library installed first > Now if you had to remove libA/1.0, you would check that no = or <= 1.0 > exists, if a >= 1.0 exists then you check that a >= 1.0 exists in libA > (which is 2.0) ...and then u remove it... > Similarly for others... _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
