This page is used to hold packaging related informations that should not be in guidelines (because they are controversial, or because we don't want to inflate the guidelines even more).
Application binary interface changes (controversial)
Application binary interface (ABI) changes in libraries (with a change in soname) should be avoided in fedora releases and done only in rawhide, except when solving a security issue or a very grave bug.
When breaking ABI, it is nice to warn on the fedora-devel-list and especially the package maintainers who depend on your package ABI. Dependent packages may be found using:
repoquery --arch=src --whatrequires mypackage-devel
Some interesting utilities exist for finding differences in ABI, and finding which package provide sonames, rpmsoname and rpmsodiff.
Acceptable use of rpath (recommendation)
Using rpath for libraries in system library directories is forbiddeen in fedora. It may be acceptable, and even desirable to use rpath for internal libraries that are nevertheless installed (for example to factor out code for different executables). That way it could be avoided to have these libraries installed on system paths. For example the libraries could be installed in:
%{_libdir}/myapp/libmyapp.so.0.3.4
And have the rpath set to %{_libdir}/myapp/.
Install dlopened objects out of %{_libdir} (controversial)
Objects that are dlopened and not linked against should not be in %{_libdir}, but in a directory below libdir where the application dlopening the object should search for. This is already the setup used by most packages, for example, there is typically a specific directory for plugins containing the dlopened objects.
Use of common namespace
Package files and directory are installed in places where name conflicts are possible. Therefore the file names should be specific of the package. This means avoiding short names (less that 3 or 4 letters), or names that are too generic (like compiler, viewer, show, convert...). There are some packages that already do that, for some it is not an issue since they are covered by a standard (like POSIX utilities cat, ls). Those issues are better tackled with upstream, but using prefix or postfix can also be used in fedora.
Avoiding using fedora or redhat in a visible manner in spec files
It is better to avoid using the words fedora or redhat in spec files, to help others wanting to reuse the spec files (be it only in EPEL). dist or distribution can be used instead. For example README.fedora could be called README.dist. Of course this doesn't cover internal details like spec file conditionals like %fedora or %rhel.