On Sun, Mar 30, 2008 at 12:07:38PM -0700, Russ Allbery wrote: > "Adam D. Barratt" <[EMAIL PROTECTED]> writes: > > On Sun, 2008-03-30 at 11:30 -0700, Russ Allbery wrote: > >> Meike Reichle <[EMAIL PROTECTED]> writes: > > >>> When doing my NM I noticed an inconsistency between the Debian Policy > >>> and the Developer's Reference concerning the use of the terms "section" > >>> and "category". > > [...] > >> The control field for specifying admin, net, utils, etc. is "Section", so > >> I think Policy wins here and main, contrib, and non-free should be called > >> categories.
In 2.4 Sections: * section if the package is in the main category, * segment/section if the package is in the contrib or non-free distribution areas. Here main is "category" contrib or non-free are "distribution areas" but their name can be used as "segment". > > For what it's worth, and possibly to add more confusion, dak uses the > > term "component" in this case. Release file downloaded to user system calls them "component" too. > Also, I guess my first reaction isn't as conclusive as I'd like, since > Section, the control field, is actually used for both. > > I sort of like component better than category. I wonder if we should > change both documents. Although I think Policy is fairly uniform and > consistent on using category, and other software, like Lintian, follows > the current terminology of Policy. I also realized confsing situation in terminology. The terminology used in Social contract is another point too. "component" seem to indicate package level component in distribution. main/contrib/non-free things are called as "area". I now use "component" for main/contrib/non-free following the Release file notation for next rewrite. Then I mention as: In the stricter Debian archive terminology, the word "section" is specifically used for the categorization of packages by the application area. (Although, the word "main section" may sometimes be used to describe the Debian archive section which provides the main suite.) More on: http://people.debian.org/~osamu/pub/getwiki/html/ch03.en.html#debianarchivebasics You can edit it (once good text is agreed.) http://wiki.debian.org/DebianReference/Package Anyway, consistency with Developer's reference is non-issue for Policy since Policy is higher level document. But Policy must be consistent with words usage by the key Debian infrastructure (DAK) to be consistent. Once Policy is consistent with DAK, Developer Reference and others can follow. Current Developer reference has some parts coming from packaging manual. That may be another source of inconsistency. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
