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

Re: Renaming 'math' section 'science'

> > Actually, in thinking about this, the whole system of categorizing packages
> > needs to be redone in Debian. How packages are organized for selection by
> > users should be much more flexible than our current system allows. What I
> > am thinking is to expand the 'Section' variable in the Packages files to
> > include subsections. This won't affect how the archive is organized, but
> > in the long run will make package selection much easier.
> > 
> > This would allow us to have categories like the following:
> > misc/dbserver        all database servers
> > misc/dbclient        all database clients
> I think database stuff should have it's own top level section.
> > math/num_anal        numerical analysis software
> > math/calculator      all calculators
> > 
> > New categories could only be added if the policy group allows it.
> > This method of organizing would allow us to create new categories and
> > get rid of old ones without having to reorganize the archive.
> > For example, if it was decided that num_anal was too broad, it could
> > be broken down into math/lin_alg and math/num_integration.
> > Thus, the existing bad section names wouldn't matter as the user won't see
> > them.
> > 
> > This would enable the user to go into an improved version of dselect or apt
> > and instead of being hit by the entire section 'web' could see the sections
> > 'web browsers', 'web servers', 'html editor', 'web log analyzer' and 'CGI'
> > and have many fewer packages to select from.
> > 
> > There are already some minor flaws I've noticed in this which are easily
> > remedied. If people like the idea I could expand upon it and bring it to
> > -policy. The big stumbling block to this would be the necessary changes to
> > the archive management programs, dselect and apt.
> I like this idea, but what about things like perl interfaces to databases.
> Should they go in databases or interpreters (interpreters/perl)? or should
> they go in both.  And then things get really ugly.
This sort of thing is something that will have to be worked out.
Clearly we don't have all the answers yet, but for 90% of the packages deciding
where to put them shouldn't take much thought.

Jay Treacy

Reply to: