[ 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
