Some clarifications: > The current policy is that the RPM package names should be identical to > the basename of the upstream tarball unless there is a technical reason > why it cannot be named this way.
Examples of technical reasons include: - Multiple versions of a package are shipped, in this case only the name of one version can match the upstream tarball, all other versions get a shortened form of the version number squeezed into the package name. - The upstream release name contains illegal characters. > I'm _strongly_ against renaming existing packages for reasons other than > a technical problem which requires the package to be renamed. This should read: Discussing new rules is of course interesting and fine, but if a new naming policy is agreed on as a result of this, it should be applied to new packages only. Existing packages should not be renamed unless they either change their meaning or there are packaging changes which force changing the name. The technical problems with renamed packages are: - The package manager somehow has to know that the new package replaces the old package. This is usually solved via Provides/Obsoletes, but it pollutes the namespace: An obsoleted package name can effectively never be re-introduced again, and even the slightest mistake in this area can have very "interesting" results. - YaST contains hardcoded package lists in several places which don't work with Provides, but only with the real package names, so renamed packages can only be handled by changing the code and nobody can guarantee that all occurances of obsolete packages are found and cought in time. - 3rd party developers use the existing package names to express dependencies (Requires/BuildRequires), changes in this area result in very ugly %if/%else blocks that make the spec files harder to read and maintain. These cannot be fixed as easily as the ones in the distribution. If the 3rd party developer doesn't notice the change, the package gets broken. Note that I do think your proposal has advantages, but in order to be really useful, it would require major packaging changes. As an example, how would you handle a package that contains both shared libraries and executables? Debian-derived distributions have a policy to split all such packages so that the executables are in a package named like the upstream release and a library package that gets a "lib" prefix and a suffix based on the interface version of the shared library. This is an advantage because it means you can have an arbitrary number of different library versions installed, but requires much more packaging work. You would have to update the BuildRequires of all packages all the time, and you would have to manually keep the package name in sync with the interface version with each upgrade. It's painful, I predict it won't work and for a centrally developed distribution it's not really necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
