On Thu, 2006-05-18 at 16:49 -0400, Matt Wilson wrote: > On Atomic Operation: I'm interested to know how you're > planning to do one atomic operation on the filesystem to move a > package from being staged to being installed. As you stage new file > contents to disk, possibly writing them along side existing files, you > have to rename() each one individually. There's no way to do this in > one atomic operation (that I know of) without help from the OS. > Each individual file would be handled atomically from a filesystem sense, the package set as a whole would be handled atomically from a package manager sense. If the entire operation doesn't complete, the package manager would revert it; and in cases of power failure, any further invocations would see the incomplete operation recorded in the journal and refuse to continue until the system was "repaired" (this may be somewhat automatic). > On Focus on Installed Packages: I see no need to keep a record > of available packages in the package manger. I do see a need to keep > at least a log of removed packages on the system. > What information about them do you log? > On Classes: Though the mechanism you've described is somewhat > different than what we've implemented, Conary implements this. We > call them "tags". Files are tagged to be of a certain class, or type. > For example, we have an "initscript" tag. The system has a "tag > handler" that knows what to do with a file that is an "initscript". > All the actions that are needed to register the initscript with the > system are stored in one place - NOT in every package. > The dpkg2 design allows for both, either stored in one place on the system or specialised in the package. The whole classes concept is pretty much lifted directly from the Solaris package manager. > On Hooks: We talked about having something like this, but we have not > found a need. Tag handlers have been sufficient thus far. > I suspect on the whole they may be, but I can also forsee cases where they conflict. For example it may be desired to put a shared library in an optional class of some kind, which would negate it being in the special class that causes ldconfig to be called. Having ldconfig called by a hook that just looks for files being installed into directories it cares about would be somewhat easier to manage. > On Architecture: I think that relying solely on the dependency > mechanism alone for architecture handling could be a mistake. When > tools are trying to filter packages down to ones that are suited for a > particular target, you don't want to have to sift through dependencies > to determine the fitness. In Conary we include the architecture > information as part of the flavor. So, extending the example above, > you have "lynx" version "2.8.5" flavor "is: x86 ssl" (where "is" > stands for "instruction set"). We also have (now using a more > Conary-specific notation) "linux=2.8.5[is: x86_64 ssl]" This is > critical to narrow the forest of available packages to ones that will > be suited for the target. > I think that dependencies are better suited to filtering than a simple string; strings require tables being maintained and kept up to date between several different pieces of software, as well as having equivalence tables, etc. Using dependencies means you follow exactly the same codepaths as you do to determine whether a package is "installable" in any normal sense. It even then allows the flexibility to install architecture support onto your system, just as you'd install ordinary dependencies first. More pointedly, it doesn't nail us to any particular posts and allows for a great deal of flexibility in the future. > On Dependencies: Please, no more dependency types. It makes > calculating solutions for dependency closure extremely hard. I think > that the focus should be on getting dependencies right. Additional > information (Enhances, Suggests) should be part of metadata, so that > frontends with more complex solution algorithms can use them. > Note that in the dpkg world, there are only a relatively small selection of true dependencies. The rest are just meta-data that allows the user interface to wiggle around a bit. I think the range of relationship expression is one of the dpkg/apt strengths. > On Multi-Arch: You note that your solution requires packages to be > modified so that packages do not contain common files. > No, it simply requires that where common files exist, the class handles the decision as to whether the shared common file is acceptable or needs to be rejected. > Overall, I'm very impressed with what you've come up with. However, > I'd like to see a few more things tackled. One problem that plagued > RPM was dealing with distribution upgrades. > This has never been a problem with dpkg, I don't believe the new implementation would cause any problems either. > As we removed one package in favor for another (xinetd replacing > inetd, for example), we relied on Obsoletes to do the right thing. > As noted this is something that dpkg currently doesn't do, and to which we're thinking about solutions to solve. I suspect it may be an extension of the existing Task field, however the design's focused a little more on the actual file management right now. (Walk before you run, etc.) Scott -- Scott James Remnant scott@canonical.com
Attachment:
signature.asc
Description: This is a digitally signed message part