On Thu, Dec 28, 2000 at 05:32:12PM -0800, esoR ocsirF wrote: > Greetings, > IANAD, but I would like to suggest an idea that I had. There has been a > lot of interest in getting packages arranged by different > catagorizations, something like the menu. Most ideas that I have seen so > far seem to imply adding new fields to the debs, but his seems like > overkill to me. > > Couldn't a new packages be created, something like a Catagories.deb that > contained a databased of entries for each type? like... > Graphics > |_Gimp > |_Xfig > etc... > and when somebody thought that a package should be added to a catagory > they just submitted a bug against the catagory package. Extra catagories > could be added by bug requests also. This would allow package maintaners > the ability to say where there packages belong but also the users would > be able to feed back into the catagories as well. > > This would require some modification to the package front ends and allow > the current system to stay intact without modification. I think that this is a reasonable idea, however, it only addresses a small part of the problem. I feel that a better solution would be to use a similar method to perl modules: a hierarchal name space. In fact, we already simulate this the way pre perl 5 did. The most obvious example of this would be the -dev packages. In my proposal, the following could happen: ... X::XFree86::4::common X::XFree86::4::servers::svga X::XFree86::4::servers::vga X::Fonts X::Fonts::FreeFonts ... X::Games::koules X::Games::lincity ... PackageManagement::dpkg PackageManagement::dpkg::frontends::apt-get PackageManagement::dpkg::frontends::aptitude PackageManagement::alien ... Daemons::MTA Daemons::MTA::Exim Daemons::MTA::Sendmail There are several side benefits to this, first, we get the catagories that you and others desire. We no longer have a flat name space and the name space pollution associated with that. For instance, the package water (that was recently discussed here) might go in Graphics::Demos::water. There may be another package named water, however, it is unlikely that it will be another demo. This is common in everyday life; look at DNS; we have the same problems (or will). Another nice benefit is that, like perl, packages are not restricted to modules; an internal node could act as a collection and leaves as modules. For instance, X::Fonts, might provide a standard collection of fonts or Daemons::Webservers::Apache might provide apache and Daemons::Webservers::Apache::Foo would provide the module foo that apache uses. A third example would be Daemons::MTA. This node could have exim, sendmail, etc as leaves, however, the node it self would point to the default that Debian choose, at the moment, exim. I could go on, however, I feel I have established several principle wins. So, who is going to implement this? Unfortunately, this email does not indicate that I am going to; my energies are focused elsewhere for a while. -Neal -- Neal H Walfield University of Massachusetts at Lowell neal@walfield.org or neal@cs.uml.edu -- Neal H Walfield University of Massachusetts at Lowell neal@walfield.org or neal@cs.uml.edu
Attachment:
pgpNdtEJsfRBY.pgp
Description: PGP signature