Не следует использовать устаревшие конструкции  — они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:

Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавиться от них можно с помощью команды cleanup_spec spec-файл

Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.

Рекомендуемый порядок заголовочных тэгов: Name, Version, Release, Serial, далее Summary, License, Group, Url, Packager, BuildArch, потом Source*, Patch*, далее PreReqs, Requires, Provides, Conflicts, и, наконец, Prefix, BuildPreReqs, BuildRequires. Разумеется, не все из вышеперечисленных тэгов используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что BuildRequires зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать BuildPreReq.

Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы. Значение тэга Summary не следует завершать точкой. Значения тэгов Summary и %description могут содержать названия команд только в не изменённом виде.

Значение тэга Group должно соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле /usr/lib/rpm/GROUPS.

При формировании первой строки changelog-записи используйте утилиту add_changelog spec-файл. Описание изменений должно быть информативным; недостаточно объявить о наличии изменений, необходимо их все явно перечислить.

Если в состав пакета входят файлы локализации либо другие файлы на разных языках, следует использовать макрос %find_lang. Подробную информацию можно получить, выполнив команду /usr/lib/rpm/find-lang -h.

При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также версию, релиз и serial (если есть). Например, «Requires: %name = %version-%release» или «Requires: %name = %serial:%version-%release». Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружён пробелами.

Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это, в частности, позволяет уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса lib либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.

Каждый пакет, содержащий разделяемые библиотеки в каталоге /lib, /usr/lib или /usr/X11R6/lib, должен их регистрировать при установке/обновлениях и удалении с помощью макросов %post_ldconfig и %postun_ldconfig соответственно.

Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: в списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.

Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать: