Есть ли «правильный» способ опакетить то, что нужно собирать. Или где об этом почитать?

Как ты себе представляешь «распространение в дистрибутиве» без «правильного опакечивания»?

Я бы тебе с таким ником предложил в msi паковать, но у тебя debian в тегах…

Ты хочешь каждый раз своё ПО на целевом ПК компилировать или я чего-то не понимаю?

Всякие питоняшные программы обычно указывают в зависимостях нужные им пакеты. А что такое преконфигурированный интерпретатор? Звучит диковато. Может написать shell скрипт, который будет запускать интерпретатор с нужными параметрами командной строки? Так обычно делают в случае с java-софтом

Конечная программа - набор PHP-скриптов.

Им нужен интерпретатор PHP с определенными модулями, не идущими в стандартной поставке.

Мне нужно, чтобы после условного dpkg -i my_de.deb - в системе оказался этот самый интерпретатор.

Установщик .sh я ему могу сделать, который по сути будет являться набором wget'ов, ./configure'ров и make'ов. Но хочу попробовать через единый пакет.

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

flatpack/appimage/snap в помощь.

А что такое преконфигурированный интерпретатор?

Это значит PHP который использует кастомные либы которых нет ни в его, ни в системных репах, а только собираемые из исходников.

Может написать shell скрипт, который будет запускать интерпретатор с нужными параметрами командной строки?

Не. Запускается оно все стандартно. Нестандартен сам Пых. Его либы тоже компилируются в .so

flatpack/appimage/snap в помощь.

Я линуксятников недолюбливаю, но не настолько =)

Конечная программа - набор PHP-скриптов.

Ну не на ночь же такое…

Им нужен интерпретатор PHP с определенными модулями, не идущими в стандартной поставке.

У пакетов есть зависимости. Почитай про них на примере тех же deb-пакетов.

Мне нужно, чтобы после условного dpkg -i my_de.deb - в системе оказался этот самый интерпретатор.

Зависимости заставят apt установить нужное перед установкой твоего пакета.

Установщик .sh я ему могу сделать, который по сути будет являться набором wget’ов, ./configure’ров и make’ов. Но хочу попробовать через единый пакет.

Почитай про post-install у deb-пакетов.

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

А обновлять потом как?

MSI — твой выбор. Ну или setup.exe)

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

Собери это всё в пакеты, пропиши в зависимости и сложи в своём репозитории для apt.

Ну не на ночь же такое…

Что тебя испугало, или удивило? Что PHP оказался годным языком для написания функционального окружения рабочего стола?

У пакетов есть зависимости. Почитай про них на примере тех же deb-пакетов.

Зависимости - у программ. Пакет - всего лишь архив программы с правилами ее установки.

Зависимости заставят apt установить нужное перед установкой твоего пакета.

Вот мне и нужно знать механизм, как в пакет помещается это самое «нужное». Потому что «нужного» - в репах нет - это зависимости которые устанавливаются компиляцией.

Почитай про post-install у deb-пакетов.

Годное замечание, благодарю.

А обновлять потом как?

wget https://repo_url/supreme.tar;mv /system/supreme /system/supreme_old; tar -xvf supreme.tar /system/;echo "Updated"

Это ж скрипты, они обновляются перезаписыванием.

Собери это всё в пакеты, пропиши в зависимости и сложи в своём репозитории для apt.

Т.е. в пакет нужно класть уже скомпилированную версию, верно?

Я даже не знаю, что тебе ответить, чтобы не обидеть и по шапке не получить от модераторов.

Для начала, почитай про checkinstall. В целях тестирования тебе может этого хватить.

Чтобы наша дальнейшая беседа имела смысл — начни изучать документацию по сборке пакетов для Debian. Странно, что ты до сих пор этого не сделал.

Годный ответ. Его нужно поставить в этот раздел плашкой, вместо текстового поля ввода и кнопки «Поместить».

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

Ладно, ответ я получил. Спс.

По хорошему тебе надо все эти зависимости опакетить каждую отдельно, можно репу свою для этого завести, тогда это будет нормально ложиться на идею пакетного менеджера. В твоем случае можно скомпилять самому и распространять готовые бинари, для красноглазых оставить инструкцию что wgetить и куда ./configureить чтоб собрать самому. Ну и можно сделать «rarjpeg» из скрипта установки и нужных бинарей, вроде как zip можно включить в скрипт, в общем посмотри как сделано, например, в soapui

если программе нужен установленный с необходимыми модулями преконфигурированный интерпретатор

Если тебе не подходит то как этот интерпретатор собран в дистрибутивах, то тебе остаётся только вендорить. При этом вендоринг в серьёзных дистрибутивах запрещён. Поэтому остаются только какие-нибудь флатпаки.

Если ты со своей версией пыха, отличающейся от версии в репозиториях полезешь устанавливать его как пакет - это верный способ поломать если не всю систему, то зависимости пакетов - точно. Так что создавай appimage (snap/flatpak/etc) и не лезь в пакетную систему.

Опакеть свою сборку пхп тоже и поставь её в виде зависимости. Заставлять «клиентов» качать и компилировать исходники точно не нужно. Пакет конечно же должен ставиться так чтобы не конфликтовать с обычным пхп. Например, в /opt/de-php или в /usr/local/de-php, ну и для конфиги тоже не забыть.

вендоринг

Что это за идиотское слово?

vendor, в переводе с англ, это поставщик-изготовитель чего-либо.

Не надо никакие rarjpeg-и, не оффтопик же. А ссылка твоя битая.

Не надо checkinstall, банить надо за такие советы.

Это значит PHP который использует кастомные либы которых нет ни в его, ни в системных репах, а только собираемые из исходников.

опакетить либы, опакетить твоё ДЕ с зависимостями от этих либ в том числе

если нужны только модули, то не надо своё пхп

Нужно, в дистрах всё плохо с ним, если тебе нужно что-то конкретное. Разные дистры, разные релизы дистров - везде будут не пойми какие версии пхп, что автора вряд ли устраивает. Проще собрать свой статический бинарник с нужными опциями и забыть про этот зоопарк.

Те, кто не сильно имел дело в пхп, не понимают одну его особенность. А именно, пхп7 это не замена для пхп5, а пхп8 - не замена для пхп7. Это всё считай разные продукты, хоть и похожие друг на друга. Дистромейнтейнеры это тоже много где не понимают.

банить надо за такие советы.

Банить надо за make install. Checkinstall хоть как-то позволяет это безобразие пресечь.

ну тогда опакеть своё пхп только для дистра, где нет нужной версии

Ответы на большинство твоих вопросов гуглятся быстрее, чем написать пост на форуме.

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

Конечная программа - набор PHP-скриптов.

можешь не париться, это говно никому не нужно

Зависимости - у программ. Пакет - всего лишь архив программы с правилами ее установки.

Зависимости именно у пакетов .deb! В пакете вообще может не быть никаких программ. Есть «виртуальные» пакеты, которые ничего в себе не содержат, кроме списка зависимостей, которые требуется установить. Вот про список зависимостей deb пакетов - Список зависимостей из deb пакета

можешь не париться, это говно никому не нужно

Даже если этим никто не будет пользоваться, кроме автора - это полезно для обучения созданию своих пакетов и их распространению на своих компах.

checkinstall ничего не пресекает, он фейково делает вид что make install-а нет, хотя на самом деле он по факту есть. У кого-то на лоре он недавно собрал пакет который пытался что-то устанавливать внутрь /sys/

Опакечивать под Дебиан? Гиблое это дело. Ты молодой, горячий, не суйся туда. Оно тебя съест.

Как говорится, берегите себя, пацаны, вы женам и матерям нужны.

если программе нужен установленный с необходимыми модулями преконфигурированный интерпретатор

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

Тебе уже предложили снап - вот именно эту проблему он и решает. Это классический dependency hell

Опакечивать под Дебиан?

Правильно опакечивать под Дебиан.

Fixed

Никто не мешает сделать rm -rf / внутри make install или postinst внутри deb пакета. Смысл не в изоляции и пресечении чего-то недозволеного.

Конечная программа - набор PHP-скриптов.

С Милторгом пишете?

С Милторгом пишете?

Нет. Ты наверное просто не в курсе этой моей истории =)

O_O С каких пор deb упаковка стала каким-то колдунством?

Всегда так было. Более мутной и запутанной документации по опакечиванию нет.

Что это за идиотское слово?

Принятый в индустрии термин. Интересно, а ты каждое слово которого не знаешь считаешь идиотским?

Ты дал ссылку на слово vendoring, а мои претензии были к слову вендоринг. Что там у англичан (или, скорее, индусов) - их дело, они часто всякую чушь придумывают и я даже не хочу её анализировать.

Понял тебя. Ну, а мы тут считаем что всякую чушь придумывают борцуны за чистоту русского языка, так что ты знаешь куда со своими претензиями следовать.

Если требуется интерпретатора php собранный с опциями/модулями не особо совместимыми с тем как собран системный php поставляемый с дистрибутивом - то в системный прификс /usr/bin такую штуку не положить - то есть интегрироваться с дистрибутивом кажется в случае такого ПО существенно сложнее чем не делать этого. Значит на текущем этапе развития проекта надо класть в префикс типа /opt/myde-1.0/bin

Определи минимальный набор завимисотей, который нужен от дистрибутива. Возможно достаточно libc, а остальное всё собрать своё. Собери всё с префиксом /opt/myde-1.0/ - условно php будет в /opt/myde-1.0/bin а libxcb/libx11 и прочие .so - в /opt/myde-1.0/lib. И в shebang скриптов прописать именно /opt/myde-1.0/bin/php. И не рассчитывать в коде ПО что запуск php из $PATH запустит нужную версию.

Новые версии libc нормально запускают софт, собраный со старыми, но не наоборот, так что собирать лучше в окружении где старый libc (типа docker c debian 10/rhel 8 или если не нравится docker - поставить их как-то иначе).

В результате такой сборки появится папка /opt/myde-1.0/ которую можно запаковать например просто в tar. А можно по сути получившийся tar перепаковать в deb/rpm/appimage

snap

Для этого же есть docker

Для этого же есть docker

Для этого - для чего именно?