(Move standard commands out one) |
(Update to be part of Conflicts Guidelines) |
||
| Line 1: | Line 1: | ||
== Where == | == Where == | ||
[[Packaging:Conflicts]] | 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) | Also, link to this section from [[Packaging: NamingGuidelines]] After Section 1.1 (will be the new section 1.2) | ||
== Conflicting Files == | |||
There are many types of files which can conflict between multiple packages. Fedora strongly discourages using <code>Conflicts:</code> to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions): | |||
{{Anchor|ManPageNameConflicts}} | |||
=== Man Page Name Conflicts === | |||
* Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz) | |||
* Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz) | |||
In the | {{Anchor|LibraryNameConflicts}} | ||
=== Library Name Conflicts === | |||
* Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/. | |||
{{Anchor|HeaderNameConflicts}} | |||
=== Header Name Conflicts === | |||
* Put the headers in a subdirectory of /usr/include. | |||
{{Anchor|BinaryNameConflicts}} | |||
=== 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. | 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: | |||
# There is a conflicting package that is not in Fedora yet (found by doing a | |||
web search, for instance) | |||
# There is no conflict yet but the filename is likely to be used by another | |||
project (something like <code>/usr/bin/parser</code>) | |||
In the | 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 == | === Standard Commands === | ||
Common names are allowed for standard commands since those will be the | Common names are allowed for standard commands since those will be the | ||
| Line 35: | Line 62: | ||
systems, and whether you've found any conflicting programs that | systems, and whether you've found any conflicting programs that | ||
implement a substantially different command with the same filename. | 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 as there's no way | |||
for us to set a <code>Conflicts:</code> tag for the package name. | |||
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. | |||
{{Anchor|OtherUsesOfConflicts}} | |||
[[Category:Packaging guidelines drafts]] | [[Category:Packaging guidelines drafts]] | ||
Revision as of 16:58, 14 April 2009
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
There are many types of files which can conflict between multiple packages. Fedora strongly discourages using Conflicts: to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions):
Man Page Name Conflicts
- Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz)
- Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz)
Library Name Conflicts
- Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/.
Header Name Conflicts
- Put the headers in a subdirectory of /usr/include.
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:
- There is a conflicting package that is not in Fedora yet (found by doing a
web search, for instance)
- 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 as there's no way
for us to set a Conflicts: tag for the package name.
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.