RFC: fix summary text for lots of packages

[Tom Lane]

[ many people wrote a lot of stuff about this already... ]

I'm generally in favor of publishing some stylistic suggestions for
package Summary-writing.  We already have a "hard guideline" enforced by
rpmlint that summaries not end with periods, so it's hard to see how
anyone could argue with style guidelines that suggest "avoid repeating
the package name in the summary", "use (or not) initial cap", "avoid
filler like 'the' or 'is a'", etc etc.  At the same time this is
ultimately about human language and so I don't like having hard rules
about it.

But to get onto something concrete: there's been no consideration at all
in this thread about what to do with packages that have multiple
sub-RPMs.  I got an auto-gripe from Richard about my packages mysql and
postgresql.  Well, those have main and sub-packages with summaries like so:

mysql: MySQL client programs and shared libraries
mysql-libs: The shared libraries required for MySQL clients
mysql-server: The MySQL server and related files
mysql-cluster: MySQL Cluster daemons and related files
mysql-devel: Files for development of MySQL applications
mysql-embedded: MySQL as an embeddable library
mysql-embedded-devel: Development files for MySQL as an embeddable library
mysql-bench: MySQL benchmark scripts and data
mysql-test: The test suite distributed with MySQL

postgresql: PostgreSQL client programs and libraries
postgresql-libs: The shared libraries required for any PostgreSQL clients
postgresql-server: The programs needed to create and run a PostgreSQL server
postgresql-docs: Extra documentation for PostgreSQL
postgresql-contrib: Contributed source and binaries distributed with PostgreSQL
postgresql-devel: PostgreSQL development header files and libraries
postgresql-plperl: The Perl procedural language for PostgreSQL
postgresql-plpython: The Python procedural language for PostgreSQL
postgresql-pltcl: The Tcl procedural language for PostgreSQL
postgresql-tcl: A Tcl client library for PostgreSQL
postgresql-python: Development module for Python code to access a PostgreSQL DB
postgresql-test: The test suite distributed with PostgreSQL

The "base" package is not (IMHO) the most interesting part of these
packages, and it really can't have a description that implies it brings
in the entire fileset.  I think if someone were to click on a "MySQL"
item in a long list of packages, they'd probably at least be expecting
the equivalent of mysql + mysql-libs + mysql-server to get installed.

You might argue that the problem could be solved by drastically reducing
the number of subpackages, but there are a whole lot of pressures
forcing things in the direction you see here; if you don't want to
savage a bunch of *other* packaging guidelines you won't get far with
that solution.

So there are at least a couple of points here: first, we lack any
infrastructure for identifying a "core" group of subpackages that might
be reasonable to install if the user just clicks on "MySQL", and second,
if we're going to have summary-writing guidelines then they'd better
address how to describe subpackages.  I'm less than convinced that
it would be productive to avoid using "MySQL" in the subpackage
descriptions.

			regards, tom lane