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

Re: Packages: an average 66321 bytes per line of description



On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek wrote:
> On Tue, Jun 24, 2003 at 10:41:59PM +0200, Josip Rodin wrote:
> > On Tue, Jun 24, 2003 at 07:17:58PM +0200, Torsten Landschoff wrote:
> > > > the worst culprits are usually sets of binary packages from the one source file
> > > > which have package descriptions like libfoo-dev = "dev files for libfoo",
> > > > libfoo-doc = "documention for libfoo", and libfoo = "runtime files for foo
> > > > library", without bothering to describe what "foo" actually is.
> 
> > > > well, duh! like nobody would ever guess that a package called libfoo-doc was
> > > > the documentation for libfoo.  tell the reader something we DON'T know.
> 
> > > But he knows what libfoo is - or at least he is just a
> > > $ apt-cache show libfoo
> > > away from that information. Do we need to duplicate the description of a
> > > library package in each and every supporting package?

not much use when you're in dselect, wondering what "foo" is and whether it's a
good or useful thing to install.

also not much use when the description for libfoo just says "runtime files for
foo", and none of the other obviously associated packages bother to describe it
either.

the person who packages it knows what it is, but he/she has to assume that the
reader doesn't and should therefore provide a brief but useful description.
not everyone catches every single announcement on slashdot or freshmeat or
sourceforge, not everyone is fully aware of every project in every niche.

> > Not all of it, but you can't object to duplicating a single sentence saying
> > what it is.
> 
> When the sentence in question is the one that goes in the short description,
> and already fills the available space without prepending "runtime files for
> foo "?  Is the concern here with the short descs (I don't expect much from
> short descs of affiliate packages), or with the long descs?

the concern is with package descriptions that assume that the reader knows
what "foo" is.

just having a brief description in one of 3 or 4 or more packages (and some
i've seen don't even bother describing it in one) isn't good enough.  each
individual package needs that brief description.
 
craig



Reply to: