On Sun, 2006-05-14 at 22:06 -0500, Frank Lichtenheld wrote: > On Sun, May 14, 2006 at 05:19:29PM +0100, Scott James Remnant wrote: > > The PDF is the first time I've ever sat down and wrote, in one document, > > what I've been thinking about for the last couple of years. While I > > think it's pretty neat, I'm hoping others will be able to find holes or > > problems with it -- or improvements they can make. > > One thing that I wondered about while reading the document are the > restriction on what filters and classes can do. As I understand it, > filters are intended to work on the meta-data and classes are intended > to reflect that meta-data in the system. > Correct, a filter isn't allowed to modify the filesystem and a class is not allowed to disobey the instructions in the meta-data. Obviously there's no real way this can be enforced, except by policy. > But lets take the proposed implementation of dpkg-divert in filters > as an example: Wouldn't that require that the filter moves a file > from a different package around (to divert it away) and changes it > meta-data (to reflect the move). Is a filter allowed to do such > things? > I think you're confusing the dpkg-divert utility and the actual in-dpkg effect of diverts here. Only the dpkg-divert utility moves files around (when given --rename), as an external tool it can do this provided it also updates the metadata for the package of the file just moved. The in-dpkg behaviour is simply that a filter realises the path of a file is under a divert, and adjusts the meta-data so that the class now places the file at the diverted location. If a file at the diverted location already existed and wasn't from the same package, it would error, just as it does today. > One other question that came up was about the resource usage to > be expected from such a new version. Since the amount of meta-data > will probably increase dramatically (by the stored conffiles, etc) > So an interesting question might be how good one can accomodate > people with rather small systems so that dpkg doesn't take a significant > amount of their space. > The current dpkg database counts for less than 0.1% of the entire used disk space of a typical Debian system. Even with the new meta-data, I can't see this reaching anything over 0,5% of the entire used disk space; especially as the new features reduce the need for "expensive" maintainer scripts (about 75% of them go away entirely). Also with the introduction of a new database format, we can introduce compression to it and other space-saving techniques. > The memory usage probably can also expected to increase, e.g. since > the dependency graph gets a lot more complex with all the "features", > and arch dependencies. Since the current version is already a real > resource-hog in that regard, special care should be taken to not > increase that in order of magnitudes or at least give people a chance to > tweak it for their needs. > While the current version is a real resource hog, I largely think this is because it has to load the entire database into memory. With a better structured database, we'll only need to load the active portions at any one time (ie. the package being considered) so the memory usage would be substantially less. Scott -- Scott James Remnant scott@canonical.com
Attachment:
signature.asc
Description: This is a digitally signed message part