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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
