Всем привет.
Завершаю поритирование шароварного Windows приложения на Linux.
Встает вопрос как его правильно поставлять?
Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get?
Какие подводные камни?
Спасибо.
UPD: GUI приложение на .NetStandard
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Завершаю поритирование шароварного Windows приложения на Linux. NW>Встает вопрос как его правильно поставлять? NW>Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get? NW>Какие подводные камни?
Intel свою вычислительную либу (TBB, MKL, etc) поставляет в виде бинаря, внутри которого сидит инсталлятор (на Яве?), умеющий работать и в консольном режиме, и в гуёвом.
Удобно для конечного пользователя, но не удобно для CI.
Мы свой софт поставляем в виде rpm для тех, кто может установить его с админскими правами и в виде архива для тех, у кого не RHEL и/или нет достаточных прав.
Подводные камни — для архива не подтянешь автоматом зависимости, типа LSB support.
Недавно появился запрос от пользователей на Dock-контейнер.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Nonmanual Worker, Вы писали: NW>Завершаю поритирование шароварного Windows приложения на Linux. NW>Встает вопрос как его правильно поставлять? NW>Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get? NW>Какие подводные камни? NW>Спасибо. NW>UPD: GUI приложение на .NetStandard
Обычно делают DEB и RPM (ну или .tar.gz для эстетов).
Но вообще опыт с линукс шароварой отрицательный. Разные глюки на разных версиях системы, и десятке оконных менеджеров.
А линуксоиды еще вдобавок хотят все бесплатно. Лучше уж под macOS делать, ее пользователи обучены и готовы платить.
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Встает вопрос как его правильно поставлять? NW>Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get?
Целиком готовое решение поставлять вместе с сервером.
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Встает вопрос как его правильно поставлять? NW>Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get?
Самый хороший вариант для пользователя (и самый хлопотный для тебя) — это репозиторий с пакетами в родном формате для основных дистрибутивов (.deb для Ububtu/Debian, .rpm для Fedora/RHEL/CentOS/OpenSUSE и т.п.).
При этом обрати внимание, что .deb для Ubuntu может не установиться или не заработать под Debian, и наоборот.
Если у тебя большое тяжелое приложение, можешь рассмотреть идею поставлять его в Snap'ах (https://snapcraft.io/). Но никто не захочет связываться со Snap'ом ради маленькой утилитки, без которой можно и обойтись.
Самый плохой вариант — это всякие там инсталляторы, которые неизвестно, что делают, и за которыми непонятно, как подчищать. Приложение должно быть очень нужным и полезным, чтобы кому-нибудь захотелось использовать инсталлятор.
Лично мне приятней всего было бы использовать стандартные средства управления пакетами своего дистрибутива. Для RHEL это dnf, т.е. нужно собрать rpm-пакет, в котором все файлы располагались бы по правильным для RHEL местам, сгенерировать нужные файлы с мета-информацией и захостить это где-либо, чтобы я мог одной командой добавить репозиторий и второй командой установить нужную программу. Можно посмотреть, как это сделано в EPEL. Для Debian концептуально всё так же, только deb вместо rpm и apt вместо dnf. С другими дистрибутивами я не работал. Сразу скажу, что отрицательно отношусь к docker, flatpak, snap и прочим кросс-платформенным средствам и если буду знать до покупки, что софт устанавливается через эти системы, то постараюсь поискать альтернативы (но в то же время допускаю, что есть люди, которым наоборот захочется чего-то подобного).
Очень важно соблюдать принципы, принятые в дистрибутиве. К примеру в RHEL сервис после установки не должен запускаться и добавляться в автозапуск, это должен делать пользователь вручную. А в Debian всё с точностью до наоборот. К счастью сейчас везде systemd, поэтому с init-скриптами заморачиваться не нужно.
Альтернатива — просто .tar.gz, в котором будут собраны статически бинарники, которые я сам распакую куда хочу, добавлю в PATH при необходимости и всё. Если это демон, то добавить туда systemd-настройки, которые я скопирую в /etc/systemd/кудато-там и подправлю пути при необходимости. Но это, конечно, не очень удобный способ, придётся вручную отслеживать обновления и тд.
Категорически недопустимо делать какие-то инсталляторы, которые что-то куда-то будут копировать на моей системе, что-то пытаться автоматически обновлять и тд. Такой софт я лично буду запускать только в специально созданной для этого виртуалке, думаю понятно, что для этого я должен очень нуждаться в таком софте.
Линукс это не одна ОС, а разные ОС, у них много общего, а
проблемы могут приносить разные, ещё могут приносить проблемы разные версии
одного линукс дистрибутива
Начните с чего-то одного и популярного, например, с актуальной версии убунту,
затем потихоньку добавляйте разные версии убунту, разные архитектуры,
другие ОС на базе ядра линукс.
В качестве примеров — посмотрите как для линуксов поставляют свои бинарники
разработчики (а не дистрибутивные майтейнеры) virtualbox, firefox, thunderbird,
steam и т.д.
Здравствуйте, Nonmanual Worker, Вы писали:
NW> Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get?
У меня Ubuntu. При условии, что у софта нет репозитория, предпочитаю использовать AppImage. Если его нет, тогда пакет (deb). Со snappy советую не связываться, скорость запуска таких приложений сильно страдает.
NW> UPD: GUI приложение на .NetStandard
Что именно для гуя используется? Ну и область, если не секрет.
Здравствуйте, rudzuk, Вы писали:
NW>> Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get?
R>У меня Ubuntu. При условии, что у софта нет репозитория, предпочитаю использовать AppImage. Если его нет, тогда пакет (deb). Со snappy советую не связываться, скорость запуска таких приложений сильно страдает.
Я так понимаю, эта самая Ubuntu собирается принудительно всех своих пользователей в snap'ы загнать. Canonical видит в этом свой исторический шанс стать чем-то вроде appstore для Linux.
Здравствуйте, Pzz, Вы писали:
Pzz> Я так понимаю, эта самая Ubuntu собирается принудительно всех своих пользователей в snap'ы загнать. Canonical видит в этом свой исторический шанс стать чем-то вроде appstore для Linux.
Ну они уже сейчас часть приложений поставляют в snap. Однако, например, из минта снап вообще собрались выкинуть. Кроме того есть конкуренция со стороны flatpak, у которого тоже есть что то вроде AppStore. К слову, скорость запуска из снапов обещают улучшить, изменив алгоритм сжатия.
Здравствуйте, rudzuk, Вы писали:
Pzz>> Я так понимаю, эта самая Ubuntu собирается принудительно всех своих пользователей в snap'ы загнать. Canonical видит в этом свой исторический шанс стать чем-то вроде appstore для Linux.
R>Ну они уже сейчас часть приложений поставляют в snap. Однако, например, из минта снап вообще собрались выкинуть. Кроме того есть конкуренция со стороны flatpak, у которого тоже есть что то вроде AppStore. К слову, скорость запуска из снапов обещают улучшить, изменив алгоритм сжатия.
У snap'а есть хороший шанс победить. Все-таки, на дектопе Убунта встречается на порядок чаще, чем Федора, и Canonical очень настырно продвигает Snap.
Из минта снап выкинули по политическим, а не техническим причинам (вот как раз эта настырность задолбала вольное сообщество минта).
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Всем привет. NW>Завершаю поритирование шароварного Windows приложения на Linux. NW>Встает вопрос как его правильно поставлять? NW>Как это вообще принято для Linux? Инсталятор, архив, скрипт, apt-get? NW>Какие подводные камни? NW>Спасибо. NW>UPD: GUI приложение на .NetStandard
Архив под все популярные архитектуры + shell скрпипт который будет вычислять правильную url под выбранную архитектуру, скачивать его, и распаковывать в заданную в командной строке директорию. Так распространяются Node, Go, .NET Core и куча софта. Очень удобно, на любой экзотике работает. и поставщику не надо с этим заморачиваться.
Для apt и deb надо поддерживать отдельный репозиторий для каждой версии каждой ветки redhat/debian последователей. Очень геморно. Так docker распространяет свой dockerd. Очень геморно ставить пользователю. Еще гугл хром так распространяется. Но там вручную пользователю ничего делать не надо. В гугле этим заморочились. Даже обновления хрома ставятся автоматом именно через dep/rpm репозиторий средствами обновления ОС.
VC>Для apt и deb надо поддерживать отдельный репозиторий для каждой версии каждой ветки redhat/debian последователей. Очень геморно. Так docker распространяет свой dockerd. Очень геморно ставить пользователю. Еще гугл хром так распространяется. Но там вручную пользователю ничего делать не надо. В гугле этим заморочились. Даже обновления хрома ставятся автоматом именно через dep/rpm репозиторий средствами обновления ОС.
а если это утилита которая обходиться сишным стандартным рантаймом
весь вывод только в консоль
VC>Архив под все популярные архитектуры + shell скрпипт который будет вычислять правильную url под выбранную архитектуру, скачивать его, и распаковывать в заданную в командной строке директорию. Так распространяются Node, Go, .NET Core и куча софта. Очень удобно, на любой экзотике работает. и поставщику не надо с этим заморачиваться.
VC>Для apt и deb надо поддерживать отдельный репозиторий для каждой версии каждой ветки redhat/debian последователей. Очень геморно. Так docker распространяет свой dockerd. Очень геморно ставить пользователю. Еще гугл хром так распространяется. Но там вручную пользователю ничего делать не надо. В гугле этим заморочились. Даже обновления хрома ставятся автоматом именно через dep/rpm репозиторий средствами обновления ОС.
Сейчас покупаешь комп — на нем сразу стоит Винда 10. Что стационарный, что ноутбук. И как пробиться Линуху? Никак! Только сервера!
F>Сейчас покупаешь комп — на нем сразу стоит Винда 10. Что стационарный, что ноутбук.
Вставляешь загрузочную флешку, грузишся, проверяешь железо и инсталишь линукс.
Поставил линукс на комп и забываешь про всякие чистки от вирусов, переустановку системы и тормоза.
И как пробиться Винде? Никак! Только в виртуалку ее, только в намордник!
Хотя есть вайн с кучей расширений, а винда с намордником (в виртуалке) только для микрософтовского же г-на и еще для хрен знает каких исключительных случаев.
Здравствуйте, sergey2b, Вы писали:
S>то всеравно придеться делать как вы описали ?
Если .deb/.rpm зависит только от того, что есть везде (например, только от glibc, причем совместимо с любой версией в разумном диапазоне), то можно сделать универсальный .deb/.rpm, который будет работать на любом дистрибутиве.
Но добавление даже минимальных дополнительных зависимостей может легко эту лепоту сломать. Например, libjpeg по-разному называется в разных дистрибутивах, даже с одинаковым форматом пакетов.
Ну и тестировать этот универсальный пакет все-же стоило бы на разных дистрибутивах, а не только на каком-нибудь одном, чтобы случайная поломка не прошла не замеченной. Вот например прямо сейчас последняя сборка Skype под Федору сломана. А казалось-бы, Микрософт вполне мог бы освоить автоматизированное тестирование.
Здравствуйте, sergey2b, Вы писали:
VC>>Для apt и deb надо поддерживать отдельный репозиторий для каждой версии каждой ветки redhat/debian последователей. Очень геморно. Так docker распространяет свой dockerd. Очень геморно ставить пользователю. Еще гугл хром так распространяется. Но там вручную пользователю ничего делать не надо. В гугле этим заморочились. Даже обновления хрома ставятся автоматом именно через dep/rpm репозиторий средствами обновления ОС.
S>а если это утилита которая обходиться сишным стандартным рантаймом S>весь вывод только в консоль
Нет таких утилит) Для картинок, шрифтов, http и ssl все юзают сторонние либы. сишного рантайма недостаточно)
есть исключения, например BoringSSL от гугла распространяется только в исходниках. Но это редкость. Его юзает Xamarin в Mono, Гугл конечно и много больший проектов.
S>то всеравно придеться делать как вы описали ?
Ну не знаю. Как вы описали можно просто на каждом ПК компилировать пользователю) Я за первый вариант который вы отрезали. Потому что кроме deb & rpm есть еще такая штука как arch, gentoo и прочие rolling дистрибутивы, и если у вас есть API, хотя бы консольный ввод-вывод в CSV, то его тоже надо поддерживать. А тут нужен первый вариант. Он универсальный. И менее геморный для пользователя. И для разработчика. Все что нужно это в цикле в докере проверить на 3х десятках дистрибутивов.
Тест в докере хорош еще и тем, что на том же самом AMD64 сервере доступны дисрибутивы под arm, arm64, mips и прочие s390x архитектуры. И для сборки и для тестирования.
