On 7/2/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote: > Hisham, > Did you disagree with the alternate location for the Dependency files > and Links as well as he has described?
My first impression was that his suggestions added to what you proposed, combining the best aspects of your and Jan's proposal. > In general, I'm pushing the links > idea for dependencies for the simple reason(s) below: > > ...file system as package manager > ...any decent package manager needs a way of tracking forward and > reverse dependencies > ...parsing through the text files which are distributed with the recipes > is not *really* tracking dependencies...its calculating them everytime! > ...not to mention that the elegance of broken links which currently show > u what's wrong where... >From what I understood in your proposal, one would see in a directory a list of links pointing to programs that depended on a given lib. This wouldn't show broken links for missing dependencies, or am I missing something? > although the Compile, Symlink, RemoveProgram scripts will need > enhancement to support this...it'll essentially tell the user (and > RemoveProgram) in a quick look, which library's old version is > outdated....which is pretty hard to do right now > > --with the symbolic links its easy to view/browse the dependencies also > using just the FS... > however, the parsing scripts will make the solution more Gentoo like > (magic script, working on files, dependencies inaccessible to user > easily other than the script)... :( I understand the conceptual motivations, but pragmatically I still feel unconvinced. Perhaps you might want to try a prototype implementation? Seeing things in practice can go a long way to get a point across. -- Hisham > Hisham Muhammad wrote: > > 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 > > > _______________________________________________ > gobolinux-devel mailing list > gobolinux-devel@lists.gobolinux.org > http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel > _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
