LINUX.ORG.RU

Правильная установка ПО под ubuntu.

 


0

3

Написал программу, которая делает хорошие вещи (собирает софт нужным образом).

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

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

Программе нужен nodejs, к нему нужен пакет minimist, который ставится через npm. Соответственно, npm тоже нужен.

Как коректно подтянуть зависимости? Должен ли это делать скрипт установки, или я могу, допустим, организовать проверку на наличие этого софта. Или скрипт установки вообще не должен заморачиваться с проверкой?



Последнее исправление: Mirmik (всего исправлений: 3)

Опакеть.

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

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

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от sudopacman

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

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

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

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

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

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

sudopacman ★★★★★
()

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

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

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

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

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

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от Mirmik

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

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

ArcFi
()

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

th3m3 ★★★★★
()
Ответ на: комментарий от Mirmik

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

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

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

KivApple ★★★★★
()
Ответ на: комментарий от th3m3

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

KivApple ★★★★★
()

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

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от Vsevolod-linuxoid

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

peregrine ★★★★★
()
Ответ на: комментарий от ZenitharChampion

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

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

petrosyan ★★★★★
()

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

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

anonymous
()

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

alltiptop ★★★★★
()

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

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

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

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

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

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

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

pup_kin
()
Ответ на: комментарий от Mirmik

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

XMs ★★★★★
()

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

anonymous
()

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

Deleted
()
Ответ на: комментарий от deep-purple

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

EBU в Ebuntu, а KBU в Kubuntu

petrosyan ★★★★★
()

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

anonymous
()

Только пакет

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

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

hobbit ★★★★★
()

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

Я хочу одновременно распространяться устанавливаться через 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(что, имхо, гораздо более правильно.), а пакет вообще не будет ни от чего постороннего зависеть.

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

Скрипт, который будет собирать мне 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
В папке src лежали исходники, в папке build проиходила сборка бинарей, в папке test-build сборка бинарей для тестов,в папку pkg-build копировались бинари из папки build и другое файло, типа чейнджлога и конфигов по умолчанию из src, затем в папке pkg-build запускались скрипты сборки deb-пакетов из дебиана (уже забыл чем там собирается, команду shlibdeps одину только и помню).После сборки пакета его можно было забрать из папки dist. Ну а названия sh-скриптов для сборки в листинге каталога думаю говорящие.

pup_kin
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.