Archive:Common package names packaging guideline draft

Where

Changes to be made to Packaging:Conflicts#Conflicting_Files

Also, link to this section from Packaging: NamingGuidelines After Section 1.1 (will be the new section 1.2)

Conflicting Files

[... This part is unchanged ...]

Binary Name Conflicts

• Convince upstream to rename the binaries to something less generic (or just less conflicting).
• In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case.

Approaching Upstream

When renaming or putting files into subdirectories, it is a good idea to try to get upstream to rename their conflicting files (for instance if they both had commands named %{_bindir}/trash. Doing some research about which has been around longer may be useful in this case but may or may not be persuasive to upstream.

If neither upstream renames, we would then approach other distributions (distributions-list[at]freedesktop.org is a good place to discuss this) about renaming that can be done in all distros. That helps end users going from one distro to another to have consistency. Length of time that the projects have been around, how popular each is, and numerous other factors may play a role in this decision. Once a decision is made, we would rename the Fedora packages to match.

Potential Conflicting Files

We don't just try to avoid conflicts with existing packages within Fedora but also potential conflicts. This is because the first package to enter Fedora is not always the one that should take on the name. There are several scenarios in which this could come into play:

1. There is a conflicting package that is not in Fedora yet (found by doing a web search, for instance)
2. There is no conflict yet but the filename is likely to be used by another project (something like /usr/bin/parser)

In the first case, where a conflicting package is known to exist but is not yet in Fedora, we should go through the process of determining which package has a more valid claim to the name and rename the files in the package we're including if it doesn't have the more valid claim. If you think your situation is unique, please send email to fedora-devel-list[at]redhat.com to make your case.

In the second case, where there is no known package to conflict with at this time, it is up to the packager to make a decision. Note that it is encouraged that you at least speak to upstream about the potential for conflicts. However, we can hope that any later projects that attempt to use that name can be persuaded to rename based on this project being around longer.

Standard Commands

Common names are allowed for standard commands since those will be the only commands to implement them. Standard commands include things provided for in published and widely implemented standards like POSIX and de facto standards such as a program that has traditionally been shipped with a certain filename as part of a large number of Unix variants. If in doubt, send a message to fedora-devel-list[at]redhat.com with details of what standards the command appears in, how long it's been available on what Unix systems, and whether you've found any conflicting programs that implement a substantially different command with the same filename.

Conflicting Package Names

Just as files can conflict, package names can as well. Conflicting package names MUST be resolved. Package names which differ only in case are still considered to be conflicting. You should follow the same basic steps outlined in #Approaching_Upstream

Renaming packages and replacing them with others can be difficult if it has to occur at a later time (for instance, upgrade paths can become complex in these situations) so it is even more important to be aware of potential conflicts here than it is with filenames.