Упаковка Cross-distribution/OS
Afaik :- в основном: использовать $@ ИЛИ `cat` (без установки $@ кому: `cat` )...
так некоторая переменная substition штука...
Править: Таким образом, это дает Вам своего рода интерактивный вход...
Вот немного Терминального теста:
localhost:~ _druu$ echo ${@:-`cat`}
hello
world
;)
^\hello world ;)
localhost:~ _druu$
Простой способ состоит в том, чтобы обеспечить исходный архив и позволить специалистам по обслуживанию распределения сделать пакеты для своего собственного распределения.
Можно легко сделать простой двоичный архив (.tar.gz) и преобразуйте его в a .deb и к a .rpm, который покроет большинство пользователей Linux, но это не будет столь же полезно как правильно сделанный пакет. Получение двоичного архива в правильном формате является только верхушкой айсберга. Создание хорошего пакета требует среди других:
- Размещение файлов в соответствующих каталогах. В то время как FHS пытается объединить структуру каталогов Linux, между дистрибутивами существует все еще изменение.
- Компиляция против правильных версий библиотек. То, насколько трудный это, зависит от того, зависит ли Ваша программа от библиотек, ABI которых развивается быстро. Различные выпуски того же распределения могут потребовать различных пакетов, потому что они поставлются с различными версиями библиотеки.
- Объявление зависимостей с правильными именами пакета.
- Объявляя записи меню, обработчики MIME, документация, запускают сценарии, …
Обычно легче позволить кому-то, кто знаком с каждым распределением, делают пакет. Часто Вы будете мочь собрать эти вклады в единственный исходный пакет (содержащий a debian каталог, a .spec файл для об/мин, …), и распределяют исходные архивы, затем позволяют людям, которые работают, каждое распределение делают пакет для их распределения. Если Вы не внесли существенные изменения в свою программу, вероятно, что, после того как Вы получаете конкретную работу распределения, более новые версии будут просто работать с теми же сценариями сборки.
Некоторые дистрибутивы автоматизировали механизмы, чтобы создать и распределить пакеты. Например, можно сделать PPA Ubuntu и создавать его автоматически против всех, поддерживал релизы Ubuntu, даже если Вы не запускаете Ubuntu.
Мое предложение, изучают их. Дело не в этом трудный и была большая автоматизация в создании их, и это обеспечивает собственный путь к системам для сообщения использования, что они на самом деле установили..
Сказав, что существует много опций:
- Об/мин может быть скомпилирован из источника, и много систем обеспечивают исходно скомпилированные порты инструмента
- APT также доступен для части ОС, которую Вы перечислили.
- Самораспаковывающийся Архив Shell, который в основном требует шара tar Вашего распределения и некоторых сценариев конфигурации сообщения.
Если не считать ответа Жиля , сейчас дела пошли немного, по крайней мере, для дистрибутива GNU/Linux, который получил несколько новых кросс-дистрибутивных пакетов, таких как :Flatpak/Flathub, Snap/Snapcraft, AppImage... Даже Homebrew и NixOS.
По-прежнему разумно оставить создание пакета разработчику, знакомому с платформой или ее рабочими процессами и политиками, но большинство из вышеперечисленных имеют отдельную домашнюю установку и некоторые ограничения поддержки/заключение. Так что имейте некоторую свободу в том, как вы структурируете свое приложение.
Попробуйте заглянуть в упаковку AppImage, которую используют MyPaint и Krita, и это потрясающе! Они предоставляют вам один файл образа, вы делаете его исполняемым, и вам не нужно беспокоиться о версиях или установленном каком-то другом пакете, который может конфликтовать и делать ваше программное обеспечение нестабильным. Это вроде как у вас целая система докеров в файле. Лучше всего, вам не нужно ничего устанавливать!!
Зацени...
Appimage.org