RFC: fix summary text for lots of packages

[Toshio Kuratomi]

Tom Lane wrote:

Note: these comments also apply to the postgresql packages.
> 
> 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

Tangent: this one looks dated.  I see client programs but not shared libs.

> mysql-libs: The shared libraries required for MySQL clients
> mysql-server: The MySQL server and related files

This one could be "Database server" or "Fast database server" or
"Popular database server"... whatever MySQL's claim to fame is.

> 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
> 
I agree with you on the core point.  MySQL is a building block on which
these packages depend.  Just like a library of code can justify putting
the language in the name or a gnome-panel applet can justify putting
GNOME in the name, I think subpackages can often justify putting the
name of the base package in the summary.

Looked at from this angle, it seems like the server binary should live
in the base package (as everything is built around an interaction with
the specific database server) and the clients should be in a *-clients
package... but that's probably something that isn't that big a deal
compared to people having gotten used to the current scheme.

> 
> 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",

This gets us off into comps.xml and metapackages which should allow this
to happen.  That might be a tangent, though.

> 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.

Yeah... I'd like to see best practices that include an example of
subpackages using the base package name and an explanation like:  When a
package is meant to work only with a specific other package, it may be
good to mention it in the summary.  This is often the case with subpackages:

  mysql-libs: Shared libraries required for MySQL clients

The libraries in this package work specifically with MySQL, not any
generic SQL database, so it's appropriate to mention that in the summary.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081122/e0bb5955/attachment.sig>