On Sun, Sep 16, 2007 at 11:45:18AM -0700, Danek Duvall wrote: > On Sun, Sep 16, 2007 at 07:34:30PM +0100, Peter Tribble wrote: > > > > It sounds rather like Conary, actually. > > Indeed it does. :)
In some ways, but not in others... > Only packages can depend on things, and only packages can be depended on. We've found this to create a very rigid operating system. In Conary, the dependency calculation is done at the package component level. Package components dependencies are actually defined by the requirements of each file in its manifest. Dependencies are classified by type, and most are auto-discovered library dependencies in our system. We've found that in the Linux world the implementation of various system components change from time to time. XFree86 got swapped out for X.org's fork for example. If every package that required a X11 environment had to be re-built when switching from XFree86 to X.org, there would be a lot of wasted effort on a package rename. > At least, that's our working hypothesis. As for partial packages, the > point is to consume bandwidth only for the bits you actually need. There's > little point in slurping down 1.6GB of Solaris every two weeks if only > 300MB has actually changed. Hear hear! > > > Our repository stores files individually, which eliminates that issue > > > -- you only ever pull exactly what you need to transition your system > > > to the package versions you've requested. > > > > How does this work without a repository? > > Without a repository? For the moment, we assume one, even if it's local. > We'll probably have to move beyond that, but I don't think it's going to > prove to be a common occurrence. As you probably already know, Conary can generated bundled changeset files that are either relative (the delta from 1.0->2.0, for example), or absolute (everything included in 2.0). The former can be distributed to clients that do not have access to the package repository to perform an update from 1.0->2.0. The latter can be used to either install 2.0 or update any system to version 2.0, no matter what version is currently installed. > > > The downside with zip in particular is that the table of contents is at > > > the end of the file, which means that you can't do anything with it > > > until you've finished downloading it. > > > > Yes, but you wouldn't want to do a software transaction until you actually > > had all the data to hand. (If you're pulling this from a repository, > > metadata > > operations could be done independently.) > > Right. One thing I didn't understand about zip archives was that each file > was compressed individually, making it possible to unpack an archive > knowing only the boundaries between the files. If the server is capable of > serving up that information while the client is downloading the rest of the > data, then we can achieve a kind of streaming. Per-file compression also allows you to construct the archive on-the-fly in the repository server. The ToC at the end of a zip archive was one reason why Conary implemented its own archive format. Cheers, Matt -- Matt Wilson Founding Engineer rPath, Inc. msw at rpath.com
