On Wed, Mar 27, 2002 at 07:35:26PM +0100, Eduard Bloch wrote: > #include <hallo.h> > Jeroen Dekkers wrote on Wed Mar 27, 2002 um 04:51:28PM: > > > We already know this, it has come up on the mailinglist twenty times > > with big threads. This won't be done before woody, I think it's better > > Oh no, I did never expect this to be done before woody. But I think we should stop talking about this and fix the remaining bugs in woody (or maybe talk on some other list where only the people interested are subscribed, debian-devel is already a very high traffic list). > > to wait for the woody release. After the woody release we can look at > > the problems and think about the solutions. > > Yes. We need a clear roadmap. I already have a lot of ideas in my mind and I really want to work on the things needed for the Hurd and *BSD. > > > Thirth level: Rest of data, acompanying the second level. > > > > And this *fixes nothing*. When Debian grows and we a 3 times as much > > packages, the Packages filesize is as big as it is now. I think my > > solutions, providing packages files for each source package, is > > I cannot follow, provide links. I must guess, and I don't think that > making multiple Packages files would improve the speed or RAM usage. It does also other things, like making distribution creation more flexible. I'm thinking of having a some kind of package file for every source package. That would include the current information and maybe a lot more things like URL of upstream, license, etc. This file would be stored in every package pool directory (i.e. pool/main/f/foobar/Packages). Then we create a lot of bigger Packages files, only including the packagename, version number and some other things which might be useful (but not too much). Those bigger Packages files can be a lot more flexible, for example we could have a different Package file for different licenses, different upstream projects (gnome, kde, gnu, X, etc), different use of machines (server, desktop), etc. I'm not sure it will increase the speed really much, it would at least make the Packages files a lot smaller. > > > "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. > > > > Isn't that exactly what "critical" is? > > No. They are lots of things that need special knowledge for > configuration. You have to read docs to undestand them. If you do not > want to see the less important configuration things at installation > time, you can change the severity level of debconf, but I cannot see a > clear way to handle with this as package maintainer. I think there are virtual consoles available when installing most packages, you can use that to read the documentation. Maybe also providing a way to read documentation with every debconf question could be nice. > Debconf is used for too much things, not for the essential configuration > things only. All extra stuff must be splitted from essential config. IMHO debconf should be used for every configurable thing. It's nice to have a common interface for this. > > Maybe because GPM is just an old unmaintained piece of crap? (Sorry > > for my rude language, but I think it's the truth.) > > It is buggy, but it is the only way to get mouse support on console. I don't know how far Marcus is with his console server for the Hurd, I think mouse support doesn't exist, but when we add it it will probably a bit better. :) > > For X, I think Branden is doing a fine job and I can really see > > improvenment in the way configuration is done. If you know a better > > way to do it, did you told it him and/or provide a patch? > > I told already, and will try to provide a patch soon. That's nice. :) Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgpg0gv82PDs_.pgp
Description: PGP signature