Опакеть.

Устанавливать программы, ещё и имеющие зависимости, в системные директории всякими скриптами и прочим make install`ами, а также предлагать это делать другим в 2017 году — моветон.

Обработкой зависимостей должен заниматься пакетный менеджер.

Если бы дело дошло до dpkg, я бы и не заморачивался, но... Я не думаю, что на этапе разработки удобно сразу хотеть пакет.

Впрочем, вполне возможно, что я не прав...

Значит, говорите, надо сразу делать пакет?

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

Не, мне желательно без подключения доп сущностей. Много чести программе из 1000 строк.

Я не думаю, что на этапе разработки удобно сразу хотеть паке

На этапе разработки можно засунуть куда-нибудь в /opt/ месте со всеми зависимостями.

Привет. В Ubuntu Linux используются пакеты UBU, являющиеся DEB-пакетами, переименованными чтобы не создавать путаницу между пакетами для Debian и Ubuntu.

Тебе слкдует просто написать SPEC-файл для сборки. Ты можешь взять уже готовый от другого пакета с nodejs-софтом. И оттуда же взять список зависимостей

В Ubuntu Linux используются пакеты UBU, являющиеся DEB-пакетами, переименованными чтобы не создавать путаницу между пакетами для Debian и Ubuntu.

А из какого ты измерения? У нас в Ubuntu .deb пакеты используются, как в Debian. И кто тебе делал межизмеренческий интернет?

То есть однозначно пакет?

С новым годом, кстати, всех.

То есть однозначно пакет?

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

С новым годом! Пусть скрипт проверяет установленные пакеты и доустанавливает нужные. В 2017 году, я думаю, это будет норм.

Я не думаю, что на этапе разработки удобно сразу хотеть пакет.

При разработке можно вообще ничего никуда не ставить и запускать софт прямо из каталога, где ведётся разработка (нормальный софт должен проверять, запущен ли он из системного каталога или из каталога сборки и не терять свои файлы).

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

Либо скрипт будет ubuntu-only, либо у него будут некоторые проблем с детектом дистрибутива и использованием соответствующего пакетного менеджера с учётом его особенностей. Причём на мой взгляд этих проблем будет даже больше, чем написать скрипт, который пакетит софт сразу под десяток разных дистрибутивов (благо, по-настоящему уникальных дистрибутивов, не так уж много - нужно опекетить под Debian-based, Red Hat-based, Gentoo-based и Arch-based, может забыл ещё что-то популярное).

Теперь я хочу сделать под это дело инсталятор (install.sh), который, соответственно перенесет все файлы в нужные разделы, пропишет мою программу в /usr/local/bin и бла-бла-бла.

Ты редиска, лучше делай сразу пакеты.

Лучше так не делать, если софт не требует особые версии патченных библиотек.

Привет. В Ubuntu Linux используются пакеты UBU, являющиеся DEB-пакетами, переименованными чтобы не создавать путаницу между пакетами для Debian и Ubuntu.

Закусывать надо!

README файл с таким содержимым:

1. Поставить ноду 2. Прописать путь к бинарнику

Запакуй все в appimg со всеми зависимостями, уж для разработки лучше нет варианта

вот первые пришедшие в голову варианты установки:

1. Скомпилировать deb-пакет. Распространять его как отдельный файл или через классический или ppa репозиторий.

2. Использовать старое и очень хорошее решение - разместить программу с деинсталлятором в /opt, в отдельной папке.

3. Сделать пакет портабельного пакетного менеджера, на выбор есть appimage,snap,flatpak.

4. Разместить прогу на битбукете или гитхабе. Сделать её портабельной ( то есть работающей из папки репозитория сразу по относительным путям ). Написать ридми для установки и пусть пользователь сам ставит её куда хочет и удаляет потом ка хочет. Пусть сам разбирается какую ветку ему качать, где транковая а где стабильная ветка. Установка в этом случае будет через git clone/hg clone. Вариант, при всей его некрасивости самый распространенный на сегодняшний день в количественном аспекте. Можно смело пользоваться таким подходом - поскольку им пользуется очень многие разработчики.

5. Исходники с make && make install && make uninstall. Как в портах фрибизиди. Пусть пользователь сам хранит каталог с исходниками чтобы при случае сделать make uninstall.

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

Пакетить на этапе разработки очень удобно — один раз пишешь короткий скрипт для continuous integration и потом не знаешь проблем

В Ubuntu Linux используются пакеты UBU

Хм.. странно, последний раз я видел EBU

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

А в минте - MIN, ага

Если зависимости из npm нет в репозитории, то вариант единственный — тоже через npm распространять.

Хм.. странно, последний раз я видел EBU

EBU в Ebuntu, а KBU в Kubuntu

Тогда в KDE Neon - NBU

Нет формата, кроме .deb, и dpkg — инсталлер Его.

Только пакет

Заморачиваться с велосипедным инсталлятором в Linux имеет смысл только в том случае, если ты распространяешь какую-нть проприетарщину, для которой Linux -всего лишь одна из поддерживаемых платформ, и тебе нужно уложиться в один инсталлятор для всех дистрибутивов Linux. (Да, я в первую очередь про игры.) И то, есть надежда, что если SNAP взлетит, то и в этом случае можно будет избавиться от велосипедов.

Во всех остальных случаях надо не выделываться и делать пакеты. Запланированное на написание инсталлятора время лучше потрать на что-то более полезное.

Допустим, у меня репозиторий в гитхабе.

Я хочу одновременно распространяться устанавливаться через make install/uninstall и с применением deb пакетов. (Как это делает 90% соообщества).

Скрипт, который будет собирать мне deb пакет мне следует держать в том же репозитории? Я deb скрипты никогда не собирал. Придется учиться это делать.

Идея с установкой в opt, видимо верная. Будем пользоваться.

snap пакеты это что-то новомодное. Mirmik не любит новомодное :). Mirmik даже от js в пользу lua отказался.

P.S. отказался от javascript. Полностью переписался на lua5.3. Использование lua лучше соответствует парадигме софта. Пока завишу от lua5.3 и пакета luafilesystem из luarocks. luafilesystem, имхо лучше будет не тягать из репозиториев, дабы не требовать luarocks, а просто тягать с собой или переписать нафиг. Может быть даже собрать всё вместе с интерпретатором lua на сишечке, благо собирать lua есть трувэй. Тогда сборка будет зависеть от liblua5.3-dev etc(что, имхо, гораздо более правильно.), а пакет вообще не будет ни от чего постороннего зависеть.

Скрипт, который будет собирать мне deb пакет мне следует держать в том же репозитории? Я deb скрипты никогда не собирал. Придется учиться это делать

Я давно deb-пакеты пакеты собирал, уже плохо помню. Тем более я свою сборку делал по шаблону который коллега использовал - поэтому плохо запомнилось. Вообще deb-пакет это просто архив с файлами лежащими в папках, при установке эти папки с файлами просто копируются в корень файловой системы. То ест вдеб-пакете лежит разложенное по папочкам то, и так, что ты хочешь положить в корень файловой системы. Установка в самом упрощенном варианте может рассматривать как обычной разархивирование деб-пакета в корень файловй системы.

Вот к примеру файлы деб-пакета CLI скулайта (только сама консольная прога и маны с чэйнджлогом): https://packages.debian.org/jessie/amd64/sqlite3/filelist

А вот файлы пакета для разработки на C и Squlite - libsqlite3-dev (Заголовочные файлы, файл статической либы, файла конфига динамической либы, сам файл динамической либы,файл pkg-config и чейнджлог): https://packages.debian.org/jessie/amd64/libsqlite3-dev/filelist

Насколько я припоминаю,у меня сборочная папка с проектом(проект был рассчитан на компиляцию и установку только через деб-пакеты, make install тогда не делал) выглядела как-то примерно так:

User@LAPTOP-7B651J4L MINGW64 /XXX
$ ls --color -la
итого 8
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 .
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:03 ..
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 build
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 src
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 dist
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 test-build
drwxr-xr-x 1 User Отсутствует 0 янв  6 09:04 pkg-build
-rw-r--r-- 1 User Отсутствует 0 янв  6 09:04 pkg-build.sh
-rw-r--r-- 1 User Отсутствует 0 янв  6 09:04 run-test.sh
-rw-r--r-- 1 User Отсутствует 0 янв  6 09:04 test-build.sh
-rw-r--r-- 1 User Отсутствует 0 янв  6 09:04 build.sh