On 7/2/07, Andy Feldman <[EMAIL PROTECTED]> wrote: > 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.
I was writing a reply to this thread while Andy's message arrived and I think he summed it up quite well; I basically agree with everything he said, with emphasis on the doubt that anything more that Carlo's grep is really needed. Some tools to scan and report on Dependencies files, like the script MJ posted, may be all we really need. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
