On Tue, 14 Oct 1997, Dale Scheetz wrote: > Thanks for your reply. It is clear that you guys have been thinking about > this. I have worried over this problem for a while myself and have a > completely different approach. > > Dpkg has a current behavior for -iGROEB that I would like to modify. > Currently under this option, dpkg starts with the archive (possibly using > the available file) and walks through the files in its view in the order > that they appear in the file system. Once it "finds" a package, it checks > the status file to see what is allowed before performing the install. > Dselect does nothing more complex than to edit this file based on what the > interface collects from the user. > > If dpkg could be either provided a new option or have -iGROEB modified the > install could be managed with existing code and handle the "ordering" > problem. All dpkg needs to do is drive itself from the status file. This > file contains directives for installation and purging (as well as Hold and > others). If dpkg were driven by this file instead of the archive, then > ordering the entries in the status file so that they satisfied the > dependencies would create a "clean" oneshot pass on the installation > process with no changes to dselect. > > How does this idea integrate with current plans for Deity?
It basically means Manoj would have make a patch for dpkg instead of making new code for Deity. This has two negative side effects, Deity still needs the dependancy code, so we have a fair amount of duplication and dpkg gets larger and more complex and starts to infringe on UI issues. Ie right now with -iGROEB dpkg will install a new version unless the package is held, Deity allows a wider range of specification. In an ideal world this code would be in a nice little library and dpkg and Deity would both happily call it to do the needed things. But since it is quite unlikely that we will be able to get anyone to rewrite enough of dpkg so that it can use our library Ian will end up rewriting our code and we will have two (supposidly) identical views of how to do dependancy. Imagine how bad things will be when we add a new feature, Deity's pkglib and dpkg will have to both be made aware of it. Yucky eh? The placement of the pkg order code doesn't really matter wheather dpkg or deity does it (dpkg would of course be the better choice) but it will rely on our core dependancy anylsis code and cache format to do all of it's processing, ie once written it should very rarely need to be changed in light of new features. This makes it hard+complex to integrate into dpkg. That is one possibility, there are a few others. Jason
