On Wed, Mar 27, 2002 at 01:53:00PM +0100, Eduard Bloch wrote: > 1) Large packages files > > dpkg and apt are designed to manage all the data in one single volume. > This may have worked fine in Slink times, but now, the volume explodes. > We need to make decissions. I suggest a three level structure: > > first level: often used packages, max. 500-1000. This volume is used as > primary target for dpkg/apt operation. It contains same data as > Packages files handle now > > Second level: names of additional packages and keywords (remember > Erich's proposal) > > Thirth level: Rest of data, acompanying the second level. I doubt that this would be a very good solution due to the diversity of Debian users. Most users would eventually have at least one package running from each of the spits making it impossible to have an improvement over the current configuration. I would suggest a solution that is much easier to manage. That is, packages should be sorted according to the date that the package was modified. This could be accompished with adding "Last Update" field to Packages that would indicate when the package is installed. This way, we could implement a partial update for Packages by the server simply parsing the "cream" from the top of the milk :) This would make fetching Packages a lot faster. This would require a small CGI on the server that would support this type of fetch, but it could save a lot of bandwidth for the server and for the user. > 2) dpkg's internal structure > > I am not very familiar with dpkg's internals, but my impression says, > that it needs memory and number of disk access times with O^2 or more. > shlib's, list files, thousands of postinst files with same and same > function could be replaced with an good database - saving space > and increasing speed. <disclaimer>Yes, I propose to change important > things. Yes, this is best done with a newer package format. No, I do not > want to port RPM.</disclaimer> Yes, and something that can be updated incrementaly without the database being constantly rebuilt on Package updates. The most important thing would be for it to remain on the HD for low end systems freeing more memory for the anctual unpack and install phases of the application. > 3) Debconf's usage. > > The current debconf'isation and how it is often done, confuses more > and more. Preinst and postinst scripts bomb you with thousands of > questions before you even got a chance to have read the docs. > We need an additional level for package's configuration state: > "fine-configured". Only essential things are configured to get the > package into the "configured" state. For all fine configuration, the > user can invoke a frontend (GUI/TUI with list selection, or CLI like > dpkg-reconfigure) and manage the rest. I don't really have a comment about this. I don't mind the way that it's done today. You can always change your answer later on with dpkg-reconfigure. > 4) Localisation: We need to provide better localisation. I am very > disappointed about base-config, which is not localised while > boot-floppies have good localisation support. We should have additional > package attributes which can be replaced by apt, so specific packages can > get higher Priority: depending on the country settings. > > 4.5) I suggest to use UTF8 as the default internal format. Unification > at this point may prevent breakage letter. > > 5) Configuration issues. The current stat is bad. Look at Knoppix, they > manage to configure X for Debian without much user interaction. It is > still not possible to make GPM and X to work together. Why cannot > Branden and Zephaniah not work together? I think that these points are best dealt by particular packages or sets of packages that are in question. Sincerely, Adam
Attachment:
pgpGvz5jPpolt.pgp
Description: PGP signature