Great idea, I'm going to put the prototype implementation together ....since the prototype might be just as involved as the logic needed in Compile,RemoveProgram...
The solution which includes all ideas discussed below, will show broken links for missing dependencies as well ... I will start working off the latest Compile/RemoveProgram based scripts...Hisham, who is presently maintaining these so I should work with that person? Thanks, [EMAIL PROTECTED] wrote: > 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 > _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
