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