Чем в баше заменить %{_lib}

/lib т.к. в 64 битных это симлик на /lib64

Похоже это от дистрибутива зависит. В 64 битной 20 федоре /lib симлинк на /usr/lib, а /lib64 указывает на /usr/lib64.

rpm --eval %{_libdir}

/lib т.к. в 64 битных это симлик на /lib64

Упоролся? Это от дистра зависит.

По теме — что требуется от скрипта?

А как написать так в баше, чтобы работало надёжно в любом линуксе?

В любом линуксе может быть очень оригинальное понятие о различиях между /lib, /lib32 и /lib64.

По теме — что требуется от скрипта?

Положить его в /usr/bin и запускать им в зависимости от битности системы /usr/lib/каталог_программы/бинарник или /usr/lib64/каталог_программы/бинарник. Вообще склоняюсь положить в исходники два скрипта и при сборке копипастить в пакет нужный.

А не проще генерировать скрипт внутри .spec файла тогда уж? Довольно распространённая практика, к слову.

Наверно проще, только башеписанины много, а она в отличии от компилируемых бинарников вымораживает.

Даже если скрипт слишком большой для here-doc, то что мешает добавить в скрипт переменную RUNPATH и сделать в .spec файле

%install

install -m 755 script.sh %{buildroot}%{_bindir}/script.sh
sed -i '/s/RUNPATH=/RUNPATH=%{_libdir}/' %{buildroot}%{_bindir}/script.sh

Даже если скрипт слишком большой

#!/bin/sh 
cd каталог_проги
./запускатель_проги

то что мешает добавить в скрипт переменную RUNPATH

Это же баш, да ещё баш с макросами, на нём что-то сложное - хуже плюсов. Замучаешься перекапывать от и до кучу литературы а потом тестить и вылавливать кучу дурных ошибок генерируемых синтаксисом экономящим символы.

В который раз убеждаюсь, что ты полностью и окончательно поехавший.

А как написать так в баше, чтобы работало надёжно в любом линуксе ?

А зачем в баше %{_lib} ? В каком месте скрипту нужно указание, где лежит чья-то библиотека ?

Если нет слов, то хоть словарик почитай, для повышения эрудиции.

А зачем в баше %{_lib} ? В каком месте скрипту нужно указание, где лежит чья-то библиотека ?

Причём тут библиотека? Чем в баше заменить %{_lib} (комментарий) Вываливать бинари в /usr/bin не всегда гигеенично и культурно. Посмотри как красиво и не засираючи, ну почти, систему ставится лазарус: /usr/bin/lazarus-ide указывает на /usr/lib64/lazarus/lazarus а у того в каталоге ещё несколько нужных ему бинарников и скриптов с правами исполняемого файла. У мну тоже с хаком: скрипт1 запускает скрипт2 а тот запускает бинарь и передаёт ему в командной строке полный путь к каталогу программы. Второй скрипт нужен на случай использования upx - он в линуксе мешает получать данные из paramstr(0)

Не нужно пользоваться UPX'ом.

Вываливать бинари в /usr/bin не всегда гигеенично и культурно.

И не надо это делать. Программа собирается в пакет, пакет ставится в правильное место (в пакетном менеджере %{_lib} есть). Далее

#!/bin/sh 

запускатель_проги

Не нужно пользоваться UPX'ом.

В смысле, из-за того что в системе может не оказаться чего-то из этого «небольшого» списочка?

$ ldd zzzzz
        linux-vdso.so.1 =>  (0x00007fff45bff000)
        /usr/lib64/freetype-infinality/libfreetype.so.6 (0x000000359f400000)
        /usr/lib64/cairo-freeworld/libcairo.so.2 (0x00000035abe00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000359a400000)
        libdl.so.2 => /lib64/libdl.so.2 (0x000000359a000000)
        libX11.so.6 => /lib64/libX11.so.6 (0x000000359b800000)
        libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x0000003012c00000)
        libgtk-x11-2.0.so.0 => /lib64/libgtk-x11-2.0.so.0 (0x0000003011c00000)
        libgdk-x11-2.0.so.0 => /lib64/libgdk-x11-2.0.so.0 (0x000000300fe00000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003013000000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000359cc00000)
        libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x000000359d000000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003ea3a00000)
        libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x0000003010600000)
        libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x0000003012800000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003599800000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003599c00000)
        libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00000035aae00000)
        libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x000000359f800000)
        libpng15.so.15 => /lib64/libpng15.so.15 (0x000000359e800000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x000000359fc00000)
        libz.so.1 => /lib64/libz.so.1 (0x000000359ac00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003599400000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x000000359bc00000)
        librt.so.1 => /lib64/librt.so.1 (0x000000359a800000)
        libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x0000003010e00000)
        libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x000000300ee00000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00000035a1400000)
        libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x0000003010200000)
        libXext.so.6 => /lib64/libXext.so.6 (0x000000359c800000)
        libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00000035a0000000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00000035a0800000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00000035a0400000)
        libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00000035a1000000)
        libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00000035af400000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00000035af800000)
        libffi.so.5 => /lib64/libffi.so.5 (0x000000300f600000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x000000359f000000)
        libXau.so.6 => /lib64/libXau.so.6 (0x000000359c000000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x000000346b200000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x000000359c400000)

Для тестирования переименовываю /lib64/libxcb.so.1 и /lib64/librt.so.1 , запускаю пожатую через upx --lzma версию бинаря и получаю

error while loading shared libraries: libxcb.so.1: cannot open shared object file: No such file or directory

Нашёл что экономить. В памяти всё равно будет жрать сколько жрал, быть может и больше, да ещё своих багов добавит. Бессмысленно.

[code]#!/bin/sh

запускатель_проги

Всё, никаких путей, кроме системных.

Выбросил из скрипта строчку c «cd» и не передал скрипту «запускатель_проги» путь, а сам он его определить не сможет (потому что определяет его по выхлопу pwd), и в результате пожатый upx`ом бинарь не будет знать где он запустился и где находятся его «подельники». А прибивать гвоздями пути в которых может работать программа «Это же не наши методы!...»(приключения Шурика)

Просто что-то не так делаешь. Для разработки/отладки можно прописать пути, а распространять следует в пакетах. И всего-то делов.

В памяти всё равно будет жрать сколько жрал, быть может и больше

Больше конечно, на 2 метра.

Бессмысленно.

Осознание факта что можешь этот бинарь уменьшить хоть так, раз пока нет нужного умного линковщика для жирного ООП тянущего много неиспользуемого кода.

Осознание факта что можешь этот бинарь уменьшить хоть так, раз пока нет нужного умного линковщика для жирного ООП тянущего много неиспользуемого кода.

Он у тебя распространяется в сжатом виде. Зачем его уменьшать на клиенте? Ты сам в треде уже кучу проблем описал, но продолжаешь грызть кактус.

А недокументированное применение? Захочет пользователь скопипастить установленную программу, а она возьмёт и заработает как надо.

Даже если скрипт слишком большой для here-doc, то что мешает добавить в скрипт переменную RUNPATH и сделать в .spec файле
...

+1. Я делаю так.

Зачем его уменьшать на клиенте?

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

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

Например в одном дистре скрипты по дефолту улетают в /usr/libexec/vendor/app, а в другом в /usr/lib/vendor/app. Вот тогда отдельный баш-скрипт в /usr/bin, который разруливает этот момент на этапе сборки пакета становится удобен

Так UPX ни хороший, ни лучший :) Просто не делай так. Да и потом, RAM куда важнее HDD, не надо её зря тратить.

Посмотри как красиво и не засираючи, ну почти, систему ставится лазарус: /usr/bin/lazarus-ide указывает на /usr/lib64/lazarus/lazarus а у того в каталоге ещё несколько нужных ему бинарников и скриптов с правами исполняемого файла.

Красиво? Это сарказм, что ли?

Программа должна либо быть в пакете, либо в виде архива, распаковывающегося в любое место.

Если она в пакете, то пользователю всё равно придётся её устанавливать, и наилучший способ — сделать либо так, как принято в конкретном дистре, либо ставить всю программу в отдельную директорию в /opt (можно сделать нужные ссылки в /usr/bin).

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

А если ты её ставишь в /usr, то ты тем самым автоматически засираешь систему. Твои извращения с иерархией файлов приводят только к тому, что ты её засираешь не так, как ожидают пользователи. Получается вдвойне плохо: мало того, что система засирается, так ведь ещё непонятно как.

А недокументированное применение? Захочет пользователь скопипастить
установленную программу, а она возьмёт и заработает как надо.

Смысл фразы от меня ускользает. :-) Что значит «скопипастить установленную программу», и чем плохо то, что «она возьмёт и заработает как надо» ?

Например в одном дистре скрипты по дефолту улетают в /usr/libexec
/vendor/app, а в другом в /usr/lib/vendor/app. Вот тогда
отдельный баш-скрипт в /usr/bin, который разруливает этот момент
на этапе сборки пакета становится удобен

Это какой-то негодный сценарий. Разница в lib и lib64 требуется только для библиотек разной архитектуры, и всё. Это разруливается на уровне системы посредством ldconfig. Никаких исполняемых файлов в %{_lib} быть не должно в нормальном случае.

Красиво? Это сарказм, что ли?

Это реализм.

Если она в пакете, то пользователю всё равно придётся её устанавливать, и наилучший способ — сделать либо так, как принято в конкретном дистре, либо ставить всю программу в отдельную директорию в /opt (можно сделать нужные ссылки в /usr/bin).

Пользователь знающий пароль рута имеет право поменять права каталогу с программой, пересобрать её бинарь для обновления, скопипастить каталог с программой в другое место или другую версию дистра.

А если ты её ставишь в /usr, то ты тем самым автоматически засираешь систему. Твои извращения с иерархией файлов приводят только к тому, что ты её засираешь не так, как ожидают пользователи. Получается вдвойне плохо: мало того, что система засирается, так ведь ещё непонятно как.

Вполне понятно, а непонятливые должны страдать или не лезть в /usr

Смысл фразы от меня ускользает. :-) Что значит «скопипастить установленную программу»

Обычная практика использования например лазаруса с дополнительными компонентами, как попользуешься этим, так вопросов не будет. Дополнительные компоненты прикомпиливаются в бинарь, естественно для этого каталогу с программой желательно выдать права на запись пользователем, хотя бы временно. Проапгрейдил (например, прикомпилил к ней движок) ты программу, а тут бац и вышла новая версия. Если будешь ставить новую то затрёшь проапгрейденную. Тогда просто копипастишь каталог с программой в хомяк, прописываешь пусковой скрипт чтобы в хомяке использовался другой каталог для временных файлов и смело ставишь новую версию, а потом используешь их обе и сравниваешь. В вики подобная технология клонирования установленного пакетами компилятора описана. Использование же нового средства разработки не всегда лучше, так как повышает системные требования к программе.

Просто в твоём дистре без пачки уникальных макросов и кучи трюков в пакетах, коих много, даже ./configure && make работать не обязано, отвык ты от разнообразия форм использования программы :)

и чем плохо то, что «она возьмёт и заработает как надо» ?

Это наоборот хорошо.

Никаких исполняемых файлов в %{_lib} быть не должно в нормальном случае.

В /usr/bin должен быть быть исполняемый файл для удобства работы с командной строкой и он там есть, а излишки туда пихать смысла нет. 1000000 файлов в одном каталоге создадут проблемы при навигации по дереву каталогов.

В /usr/bin должен быть быть исполняемый файл для удобства работы
с командной строкой и он там есть, а излишки туда пихать смысла нет.

Так я и в /usr/bin не предлагал пихать просто так. Фактически, есть два варианта. Либо ты разработчик приложения и вполне можешь себе что-то сделать одноразово (или ты между системами скачешь и не знаешь, какая у тебя может оказаться в текущий момент?), либо ты пользователь пакета, а пакет должен уже стандартно быть разложен. Либо я что-то не понимаю. :-)

или ты между системами скачешь и не знаешь, какая у тебя может оказаться в текущий момент?

И это тоже.

либо ты пользователь пакета, а пакет должен уже стандартно быть разложен.

Так он и разложен в пределах стандартного: запускаемый исполняемый файл в одном месте а реализация в другом, но минимально размазано по системе. Не в /usr/share же архитектурно зависимые реализации складировать. Если бы программа использовала файлы пригодные для многих других программ, тогда понятно зачем их размазывать по системе, делать общими для всех и нести ответственность за совместимость, а зачем так распылять уникальные файлы? Экономии дискового пространства это не даст.

Не в /usr/share же архитектурно зависимые реализации складировать.

Нет конечно. Туда - архитектуронезависимое только.

Если бы программа использовала файлы пригодные для многих других программ,
тогда понятно зачем их размазывать по системе, делать общими для всех и нести
ответственность за совместимость, а зачем так распылять уникальные файлы ?

А зачем они, тогда, в виде библиотек ? Или тут речь о плагинах ? Но, всё равно, для собранного под конкретную архитектуру пакета место уже определено заранее. Соответственно, задавать это должен пакетный менеджер на этапе опакечивания. По идее.

А зачем они, тогда, в виде библиотек ? Или тут речь о плагинах ?

В виде всего что там есть, в том числе и текстовых файлов. Всё равно одновременно 32 и 64 битные версии пакетов не поставишь - /usr/bin один на всех.

Соответственно, задавать это должен пакетный менеджер на этапе опакечивания.

Вот и будет выбирать использовать для размещения каталога /usr/lib, /usr/lib64 или любой другой прописанный в /usr/bin/пусковой_скрипт. В /usr/lib* каталогов много, если одним с уникальным именем больше, то кому от этого хуже?

В общем, так не хорошо. Выбор на этапе формирования пакета должен происходить. Рабочее синсталлированное приложение, в общем случае, не должно заниматься поиском компонент в зависимости от архитектуры. Лишнее это.

Выбор на этапе формирования пакета должен происходить.

А если всё нужное лежит в одном каталоге, который можно класть куда угодно, то так и будет. А если в скрипте прописан другой путь, то его можно поменять хентайным редактором sed.

Рабочее синсталлированное приложение, в общем случае, не должно заниматься поиском компонент в зависимости от архитектуры.

Ну так если в баше с этим криво, то и не будет. Так или иначе запустится исполняемый файл, узнает своё местонахождение и вычислит где относительно его лежат ништяки. Система как у отвязанной от реестра виндовой игры или простого видеоредактора нарезальника файлов.

Система как у отвязанной от реестра виндовой игры или простого видеоредактора нарезальника файлов.

Да в том-то и дело, это - лишнее и не сильно нужное в Linux. :-)
Можно, но смысла не много в общем случае.

Для мелких утилит может и лишнее, но засорять систему распылением самодостаточных программ, смысла ещё меньше. И так, открываешь в файловом менеджере /usr/bin смотришь на красную лампочку и ждёшь пока система натрахается с 100500 файлами. В каждый надо заглянуть, проверить картинку, считать свойства, выделить под данные память...

И так, открываешь в файловом менеджере /usr/bin

зачем ?

Часто надо, ты не поверишь. В линуксе это почти тоже самое что и в винде что-то с реестром поделать.

Часто надо, ты не поверишь. В линуксе это почти тоже самое что и в винде что-то с реестром поделать.

А ты в винде часто с реестром что-то делаешь?

Часто надо, ты не поверишь.

Действительно не поверю. Зачем ?

Чтобы пользоваться линуксом рабочей станцией. Ты не поверишь, но есть и такая опция при установке, хотя называться она может не совсем так. Если бы мне был нужен голый преголый десктоп, может быть остановился на вашем дистре, он как раз на таких пользователей больше расчитан.

А ты в винде часто с реестром что-то делаешь?

Теперь её включаю очень редко, а раньше - регулярно. Во первых, надо было заныкать файлы реестра чтобы вручную починить систему, если автопочинка реестра откажется работать из-за принципов. Во вторых - автостарт приложений прописывается тоже там, если не желаешь светить скриптами в каталоге «автозапуск». В третьих - приложения туда пишут и иногда надо это дело посмотреть/поправить. Например, нет у тебя инсталляционного образа игры а тебе надо притянуть её на другую систему - копипастишь игру и ту хрень что она написала в реестре.