Re: Bug#12509: fdutils: Data not belongs to description
Hi,
I find the Packaging manual to be ambiguous as far as this
issue is concerned. I am including all that I thought was relevant to
the issue below. I do not see a prohibition on additional information
that may help the user choose packages (quite the contrary).
It has been argued that the author name could be important in
deciding whether to install a package on not -- if I see a package
xyyzzt -- A wholly re-written text based news management system
I am likely to ignore it -- until I notice it was written by, Say,
Larry Wall, or Donald Knuth ;-)
I have to concede that this information is probably better
some place else -- like in a separate header field. In fact, I think
there was a motion earlier to expand package headers by two or thre
lines (Author(s) and URL(s); multiline fields); It seems to have died
out. Until something like that is implemented in policy, I see no
harm in people putting the correct attribution in the description
field.
manoj
======================================================================
Debian packaging manual - chapter 7
Descriptions of packages - the Description field
The Description control file field is used by dselect when the user is
selecting which packages to install and by dpkg when it displays
information about the status of packages and so forth. It is included
on the FTP site in the Packages files, and may also be used by the
Debian WWW pages.
The description is intended to describe the program to a user who has
never met it before so that they know whether they want to install it.
It should also give information about the significant dependencies and
conflicts between this package and others, so that the user knows why
these dependencies and conflicts have been declared.
[...]
Do not include the package name in the synopsis line. The display
software knows how to display this already, and you do not need to
state it. Remember that in many situations the user may only see the
synopsis line - make it as informative as you can.
The extended description should describe what the package does and how
it relates to the rest of the system (in terms of, for example, which
subsystem it is which part of).
The blurb that comes with a program in its announcements and/or README
files is rarely suitable for use in a description. It is usually aimed
at people who are already in the community where the package is used.
The description field needs to make sense to anyone, even people who
have no idea about any of the things the package deals with.
======================================================================
--
Like almost all old [more than 70 years], large [more than 10,000
people] institutions, the government did not get to be as successful
as it is by acting the way it does now. Paraphrased by
estell%fidler.decnet@nwc.navy.mil from the original statement by
Robert Townsend, in _Up the Organization._
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
Reply to: