Bug 46587

(Ответ для Alexey Sheplyakov на комментарий #0)

> Возможно проблема вызвана тем, что в спеке используются макросы
> %_alterator_libdir, %_alterator_datadir и прочие, которые нигде не
> определены.

Нет, это отдельная проблема.

Created attachment 13542 [details]
патч

Так исправлять в данном случае нельзя: в проекте используется макрос %makeinstall, который переопределяет все директории с префиксом %buildroot. Поэтому, видимо, и использовались относительные пути.

Created attachment 13627 [details]
Вычисление относительного пути вместо константы в коде

Посмотрите, пожалуйста, решает ли вашу проблему такой патч.

(Ответ для manowar@altlinux.org на комментарий #4)
> Создано вложение 13627 [details] [подробности]
> Вычисление относительного пути вместо константы в коде
> 
> Посмотрите, пожалуйста, решает ли вашу проблему такой патч.

Нет, не решает. Потому что путает libdir и libexecdir (/usr/libexec)

(Ответ для manowar@altlinux.org на комментарий #3)
> Так исправлять в данном случае нельзя: в проекте используется макрос
> %makeinstall, который переопределяет все директории с префиксом %buildroot.

Обратите внимание, что команда `ln -sr` создаёт ссылку с относительным путём.

> Поэтому, видимо, и использовались относительные пути.

Я тоже использую относительные пути, хотя при беглом взгляде это может быть и не совсем очевидно.

(Ответ для Alexey Sheplyakov на комментарий #5)
> (Ответ для manowar@altlinux.org на комментарий #4)
> > Создано вложение 13627 [details] [подробности]
> > Вычисление относительного пути вместо константы в коде
> > 
> > Посмотрите, пожалуйста, решает ли вашу проблему такой патч.
> 
> Нет, не решает. Потому что путает libdir и libexecdir (/usr/libexec)

... в чём изначально и была проблема.

(Ответ для Alexey Sheplyakov на комментарий #6)
> (Ответ для manowar@altlinux.org на комментарий #3)
> > Так исправлять в данном случае нельзя: в проекте используется макрос
> > %makeinstall, который переопределяет все директории с префиксом %buildroot.
> 
> Обратите внимание, что команда `ln -sr` создаёт ссылку с относительным путём.
> 
> > Поэтому, видимо, и использовались относительные пути.
> 
> Я тоже использую относительные пути, хотя при беглом взгляде это может быть
> и не совсем очевидно.

Ой, точно.

(Ответ для Alexey Sheplyakov на комментарий #5)
> (Ответ для manowar@altlinux.org на комментарий #4)
> > Создано вложение 13627 [details] [подробности]
> > Вычисление относительного пути вместо константы в коде
> > 
> > Посмотрите, пожалуйста, решает ли вашу проблему такой патч.
> 
> Нет, не решает. Потому что путает libdir и libexecdir (/usr/libexec)

А откуда берётся /usr/libexec? Я вижу, что вы предлагаете относительный путь до $(libexecdir)/alterator/interfaces/guile. Я предлагал использовать $(ALTERATOR_LIBDIR)/interfaces/guile, но это то же самое, потому что ALTERATOR_LIBDIR=$(libexecdir)/alterator. В обоих выражениях фигурирует $(libexecdir), но он у нас при установке определяется как libexecdir=%buildroot/usr/lib, а не /usr/libexec. Я так понимаю, что именно исходя из этого в коде было задано константой ../lib/alterator.

Судя по тому, что у вас возникает "/usr/lib/alterator/interfaces/guile but it is not installable", файлы устанавливаются в другое место. В какое? Можете показать, пожалуйста, вывод rpm -qlp на собранный пакет?
Установка происходит в alterator/build/backend.mak, но там тоже libexecdir = /usr/lib даже по умолчанию (при вызове из %makeinstall должно прилететь то же самое).