Обсуждение:Spec
Стиль
По традиции, тэги пишутся с заглавной буквы (Name, Version, Release, и т.п.).
Комментарии пишут к тому, что нуждается в комментарии; тэги, которые есть в каждом спеке, лучше не комментировать.
Точка в конце Summary указывать не следует.
BuildRequires странный, содержит пакеты, которые всегда присутствуют в сборочной среде, а также пакеты, которые на самом деле не нужны для сборки.
У нас нет полиси указывать provides: bundled(). Нужны веские основания использовать носимые с собой zlib, lz4, и magic вместо системных.
Вместо
%dir %{_datadir}/%{name}/%{version}
%{_datadir}/%{name}/%{version}/*
можно написать
%{_datadir}/%{name}/%{version}/
аналогичную замену можно сделать и в других местах.
-- ldv@
...а затем напустить cleanup_spec и получить наконец %_datadir/%name/%version/
-- mike@
Промежуточные upstream-релизы
Для линеаризации номера версии в git можно использовать git describe: * 1.0-alt1.git1.5.4-1-g18208b2
Во-первых, это не сработает. Дефисы в релизе (как и в версии) недопустимы.
При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release: * 1.0-alt1.r6543
Не согласен. Почему так? промежуточный релиз относится к апстримной версии, ему место в версии.
- Обсуждать здесь не имеет ни малейшего смысла. Имеет смысл обсуждать в devel@. --dottedmag 19:55, 14 марта 2009 (UTC)
Согласен с несогласием Михаила. Сам некоторое время использовал релизы следующего вида: 3.2.2_7_g39420d7-alt1 . Однако недавно понял, что в этом случае rpm иначе трактует старшинство версий. : 3.2.2_7_g39420d7-alt1 < 3.2_40_g39420d7-alt1
Ищу истину в данном вопросе.
-- ИльдарМулюков 10:02, 18 августа 2010 (UTC)
- Я обычно кладу SCM-ные идентификаторы (кусок хэша, ревизию) в %changelog и при необходимости увеличиваю Release:. Припоминается обсуждение в devel@, но аргументов и даже слов сейчас сходу не вспомню. --mike 22:25, 12 октября 2011 (MSD)