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

Command-line tool for programmers: which value for “Section” field?



Howdy all,

Does a package, whose primary purpose is to install an application that
is a development tool for some specific programming language, belong in
“Section: <lang>”, in “Section: devel”, or some other section?


The recently-added Lintian tags ‘library-package-name-for-application’
and ‘application-in-library-section’ are IMO quite valid in general.
Packages whose primary purpose is *not* a library, but an application,
should not have a name or section that implies they are a code library.

In the corner case of a package whose primary purpose is an application,
that is itself a development tool, for a specific programming language
(e.g. Python), what “Section” value is appropriate?

* If the package belongs in “Section: devel” because it's useful only
  for developing programs in some language, that means it won't show up
  in the specific section for that language. So what's the justification
  for putting it in “Section: devel”?

* If the package belongs in “Section: <lang>”, that contradicts the
  normal assumption that such sections are primarily for *libraries* of
  program code, not command-line applications. So what's the
  justification for putting it in this section?

* If the package belongs in some other section, that seems to conflict
  with it being at least somewhat suitable for either of the above two
  sections. So what's the justification for the specific other section
  to choose?


I'm raising this from the context of the ‘python-coverage’ package. It
is a question broader than this one package, though, and I wonder what
the consensus is, and what principles emerge to follow in choosing to
categorise such language-specific development .

-- 
 \     “Not to be absolutely certain is, I think, one of the essential |
  `\                         things in rationality.” —Bertrand Russell |
_o__)                                                                  |
Ben Finney


Reply to: