Re: identical extended descriptions
Joey Hess <joeyh@debian.org> writes:
> This is *not* a small problem. It is an epidemic. One package in 17 has the
> problem!
That is, less than 6% of packages.
> Packages exhibiting this problem, by md5sum of their long descriptions
> (note that this probably misses some that have long descriptions that
> vary by 1 letter or so):
<snip packages list>
There seem to be quite a few library, library-dev pairs in the list, and I
agree with you that these should not share the same description. However I
tend to think it is reasonable that similar major versions of kernels
(2.2.10 vs 2.2.12) can share the same extended description.
> see shy jo, who hates having to grep around in the packages file time and
> time again to prove his points.
Your effort in producing the list did prompt me to have a look at the
relevant parts of policy:
<<<<<
2.3.3. The description of a package
-----------------------------------
Every Debian package must have an extended description stored in the
appropriate field of the control record.
The description must be written so that it tells the user what they
need to know to decide whether to install the package. This
description should not just be copied from the blurb for the program.
Instructions for configuring or using the package must not be included
-- that is what installation scripts, manual pages, Info files, etc.
are for. Copyright statements and other administrivia must not be
included -- that is what the copyright file is for.
<<<<<
I think the guiding principle above is sound, that the description must tell
the user what they need to decide whether to install the package. Certainly
the netscape packages (libc5 vs libc6) versions you pointed out would seem
to be a case in point.
However if you look at the packaging manual (section 7), it contains the
following:
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.
...
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).
So far we have 3 places with slightly different statements of what the
description should be. I do concede there is a case for clarifying this
section of policy.
Regards,
Martin.
Reply to: