[newbies] проблемы с инитскриптом

[Michael Shigorin]

On Wed, Nov 17, 2010 at 06:49:52PM +0300, Андрей Черепанов wrote:
> > Собрал новую версию preload. В результате после сборки
> > sisyphus_check ругался на вот такое:
> > 
> > /.out/preload-0.6.4-alt1.x86_64.rpm: forbidden requires:
> > /etc/rc.d/init.d(daemon) /etc/rc.d/init.d(killproc)
> > sisyphus_check: check-deps ERROR: package dependencies violation

Во времена 2.3 произошло изменение в обработке инитксриптов --
с функций redhat-style произошёл переход на свои, созданные с
использованием дебиановского start-stop-daemon.  К сожалению,
не припомню, где это должно быть документировано на вики.

> > Проблему сборки я "решил" добавлением в начало спека:
> > %add_findreq_skiplist /etc/rc.d/init.d/preload
> > Но у меня очень серьезные подозрения, что так делать неправильно.

Уже хорошо, что понимаете.

> # install pdf documentation
> install -D --mode=0644 %SOURCE1 
> %buildroot/%_defaultdocdir/%name-%version/%name.pdf

Скорее в качестве цели просто ".", чтоб потом подобрать из %doc
(который заодно отметит файл как документацию -- см. rpm -qd).


On Wed, Nov 17, 2010 at 06:52:57PM +0300, Alexey I. Froloff wrote:
> 4. Зачем нужно было добавлять в спек эти чудовищные переводы
> Summary и Description?

Ты вот столько с ними воюешь, а хоть бы задокументировал
rationale вместе с указанием на specspo на вики.  Ссылку-то
подсунуть быстрее, экономичней и эффективней ;-)

> 5. Почему и отчего издохли попуга^Wстарые патчи?

Очевидно, поотваливались и не было желания/возможности вникать.
Некоторые пакеты старые патчи якорят так, что получается даже
больше вреда -- можно было бы выкинуть chroot patch и
рекомендовать размещение в отдельном контейнере, так нет,
бьёмся и обламываемся.


On Wed, Nov 17, 2010 at 07:05:37PM +0300, Dmitry V. Levin wrote:
> Что касается вашего вопроса про preload.init.in, то вы
> совершенно зря выкинули preload.alt.preload.init.patch;

BTW обычно альтовский инитскрипт проще написать с нуля по мотивам
апстримного (if any) и /etc/init.d/template, чем оформлять патчем.


On Wed, Nov 17, 2010 at 07:09:37PM +0300, Anton Chernyshov wrote:
> Это "сырой" вариант, который я выложил для решения проблемы с
> find_requires.

Это уже не со сборкой, а с проверкой соответствия policy в части
инитсктиптов.  Работать-то оно и с этим инитскриптом может,
см. тж. /etc/init.d/functions-compat и $WITHOUT_RC_COMPAT.

> > 1. Для начала запусти buildreq  для получения сборочных
> > зависимостей. А то glib2 явно прибит, хотя вытягивается
> > glib2-devel
> Я это убрал уже. Запушивать не стал еще раз, потому что исправление
> мелкое и вносить много чего придется еще.

На практике пушить стоит всё, в чём уже уверен. :)

> > В %files проще было прописать:
> > %doc %SOURCE1 README AUTHORS ChangeLog TODO THANKS NEWS
> Такой вариант не проехал, потому пришлось через заднее крыльцо все запихивать.

А как ругалось?  Не уверен, что раскрывшийся %SOURCE1 тут сгодится,
я в таких случаях обычно делаю:

%install
cp -a %SOURCEx .

%files
%doc that_source_name.txt

On Wed, Nov 17, 2010 at 07:39:52PM +0300, Mikhail Efremov wrote:
> > > 2. Ты уверен, что лицензия такая?
> > В COPYING написано, что да.
> Там просто текст лицензии. Загляните в шапку любого исходника,
> это явно %gpl2plus.

До сих пор этот макрос определён отдельно и требует
BuildRequires: rpm-build-licenses

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/