[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: pools and catagories of packages

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


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 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

Reply to: