LINUX.ORG.RU

Как правильно создать пакет для установки своей программы?

 , , ,


0

1

Здравствуйте,

Имеется программа, которая вполне уже работает. Разработка делалась на Windows, но хотелось бы всё это запустить и на Linux-ах с Mac-ом. Пришлось озаботиться созданием пакетов на Linux-е.

Сейчас использую Fedora-64 на вируталке. Нашел инструкцию по созданию deb-пакетов. Пакет вроде как создался, но при попытке его установить через sudo dpkg -i mdev_0.1_amd64.deb получаю сообщения, что нужные пакеты freetype и wxwidgets отсутствуют.

dpkg: dependency problems prevent configuration of mdev:
 mdev depends on freetype; however:
  Package freetype is not installed.
 mdev depends on wxwidgets; however:
  Package wxwidgets is not installed.

Однако команда rpm -qa показывает, что пакет freetype уж точно установлен:

freetype-2.6.5-9.fc25.i686

Да и wxWidgets тоже есть, иначе бы программа не запускалась.

В файле control пакета я, действительно, вписал строчку:

Depends: freetype, wxWidgets

Но как бы они же установлены.

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

Короче, я не понимаю принцип, как это надо делать правильно. Или надо делать под каждый пакетный менеджер отдельно ? В общем хотелось бы получить хоть какое-то универсальное решение.



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

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

Именно так. Поэтому, например, у yandex браузера делают и rpm, и deb пакеты одновременно.

И ещё примеры

https://github.com/doublecmd/doublecmd/releases/tag/v1.1.21

rpm, deb, portable, appimage

https://www.onlyoffice.com/ru/download-desktop.aspx

deb, rpm, snap, flatpak, appimage

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

Тогда я не понимаю следующее… вот, например, есть библиотека freetype, которая, как я слышал, в Linux-е часто уже установлена. Но… она же установлена конкретным пакетным менеджером (в моем случае rpm и получается, что другой пакетный менеджер её не видит, хотя у меня там ещё yum есть. Допустим я хочу сделать пакет для yum, но yum эту freetype не найдет. Тогда я её, по уму, должен предложить поставить. И получится, что у меня устанавливается вторая freetype, причем это я даже не знаю, какая из них будет реально вызываться. Это нормально так делать ? Или выход в том, что на одной OS должен всегда стоять только один пакетный менеджер и точка ?

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

Собирай статическую сборку в tgz как делает мозилла для фаерфокса и тандербёрда.
Исходники на гитхаб, мейнтейнеры соберут сами если им надо будет.
Разве что в для самообучения имеет смысл заморачиваться с бездонными и бесполезными знаниями по особенностям сборки под 10++ дистров.

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

Или выход в том, что на одной OS должен всегда стоять только один пакетный менеджер и точка ?

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

Если хочется, что бы программа устанавливалась в данном дистрибутиве, есть самый лучший способ:

Добиться того, что бы на твою программу обратили внимание сопровождающие (maintainer) данного дистрибутива. Тогда пакет с этой программой попадёт в основные репозитории и будет устанавливаться пакетным менеджером без всяких дополнительных сайтов и прочих ухищрений. Основные массовые программы так и устанавливаются в дистрибутивы.

Остальные способы можно понять из примеров выше. Если не знаешь, что такое snap, flatpak и AppImage — есть поиск, информация легко доступна.

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

Ещë пример

https://gitlab.com/pyspread/pyspread

Installation

It is recommended to install pyspread as a package that is provided for your operating system. The table below shows for which operating systems, pyspread is available in which version.

greenman ★★★★★
()

но при попытке его установить через sudo dpkg -i mdev_0.1_amd64.deb получаю сообщения, что нужные пакеты freetype и wxwidgets отсутствуют. Однако команда rpm -qa показывает, что пакет freetype уж точно установлен

У dpkg и rpm свои базы пакетов, они не проверяют наличие библиотеки, а смотрят по базе установлен ли пакет с нужным именем.

Смешивать rpm и deb пакеты на одной системе не рекомендуется.

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

в моем случае rpm и получается, что другой пакетный менеджер её не видит, хотя у меня там ещё yum есть. Допустим я хочу сделать пакет для yum, но yum эту freetype не найдет

yum это обёртка к rpm так что всё найдётся. В целом популярных видов пакетных менеджеров всего два - это rpm и deb. Используют тот, который стандартный для твоего дистра (у федоры это rpm), пытаясь использовать менеджер из не своего дистра ты в лучшем случае поймёшь что он толком не работает, в худшем сломаешь себе систему.

Так что делай rpm и deb. deb проверяй в дебиане (и собирай лучше в нём же).

firkax ★★★★★
()

Универсального решения не существует.

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

для самообучения имеет смысл заморачиваться с бездонными и бесполезными знаниями по особенностям сборки под 10++ дистров.

Могли бы уже опенсорсный ИИ для этого сделать. На входе адрес репозитория, который надо опакетить, на выходе - комплект пакетов под разные пакетные менеджеры. Сделай, скажете вы. Нет вы сделайте, вы умные.

Shushundr ★★★★
()

Как правильно создать пакет для установки своей программы ?

Целое дело. Тем более из оффтоповских исходников.

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

В целом популярных видов пакетных менеджеров всего два - это rpm и deb

Вот теперь всё стало намного понятнее. Я было пошёл пробовать создать rpm-пакет, но сразу же сел в лужу. Команда rpmdev-setuptree почему-то не делает вообще ничего, хотя должна вроде как создать структуру каталогов. Пользователь root, поэтому вроде как права не должны влиять. А можно это всё ручками создать или там запутаешься без автоматизации ?

Odin_KG
() автор топика

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

Если собираешь CMake, то в нем есть cpack, который умеет сам делать пакеты и под рпм, и под деб

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

Если собираешь CMake, то в нем есть cpack, который умеет сам делать пакеты и под рпм, и под деб

У меня специфика программы такая, что желательно вообще сгенерировать всё программно самостоятельно.

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

можно rpm или deb вообще ручками собрать :) это набор правильно архива дерева програмки и управляющих файлов для пакет-менеджера, но для этого надо знать структуру пакета и как он работает.
как обычно надо изучить документацию и настроить работу пакетника.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)

Сейчас использую Fedora-64 на вируталке. Нашел инструкцию по созданию deb-пакетов.

Федора использует rpm. Если тебе нужен пакет для федоры, ищи инструкцию по rpm. Если тебе нужен deb пакет, то поставь себе дебиан или убунту.

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

Тогда я не понимаю следующее… вот, например, есть библиотека freetype, которая, как я слышал, в Linux-е часто уже установлена. Но… она же установлена конкретным пакетным менеджером (в моем случае rpm и получается, что другой пакетный менеджер её не видит, хотя у меня там ещё yum есть.

Есть rpm, поверх него yum как оболочка. Оболочка ищет недостающие пакеты, скачивает и передаёт rpm для установки. Что установлено знает rpm. Но только то, что сам поставил.

Есть deb, поверх него apt…

Есть gentoo …

Но все они не знают друг об друге.

Так что зоопарк.

А ещё версии библиотек в системах разные. И тут танцев не меньше.

  • Можно собирать под десяток-другой ОС свой пакет.
  • Можно собирать только под несколько старых. Аля rpm на OracleLinux, deb на Debian.
  • Можно собрать AppImage, и надеяться что эта зараза запуститься.
  • Можно сложить все зависимости в /opt/myapp-0.1.0 и упаковать в tar.gz.
AlexVR ★★★★★
()
Ответ на: комментарий от debugger

Федора использует rpm. Если тебе нужен пакет для федоры,ищи инструкцию по rpm.

ну, как бы да… просто мне надо, чтобы работало если не везде, то у большинства. Поэтому мне абсолютно не важно Fedora у меня или не Fedora - это чисто для экспериментов

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

На одной ОС должен быть один пакетный менеджер. Но yum не является пакетным менеджером, он под капотом вызывает rpm. Аналогично apt под капотом вызывает dpkg.

А вот dpkg и rpm взаимоисключающи. Управлять системой должен кто-то один. Иначе система превратится в кашу.

Это правило не касается всяких пакетных менеджеров от языков программирования - pip, npm - они спроектированы чтобы ставить пакеты в свои отдельные подкаталоги не пересекающиеся с системным пакетным менеджером. Аналогично appimage, snap, docker.

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

дык и сделай пакеты для большинства дистрибутивов.
и потребителю не важно что у тебя федора али не федора - ему нужен пакет могущий установится на его дистрибутиве. вот и сделай под каждый дистрибутив.

вариант2: делаешь один «универсальный пакет» appimage flat snap и подобные. они правда требуют наличия запускалки для своего формата и она не везде есть… но кагбэ «универсальные» :)

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

запускалку он имет внутри себя в виде ибнаря вначале, но в принципе, «тож самое но только другое»

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

Установка deb пакетов в федору чревата нехорошими последствиями вплоть до создания топиков в General «Сломал федору, как оживить». Чужие пакетные менеджеры обычно используются для других целей типа создания контейнеров дебиана в федоре.

чтобы работало если не везде, то у большинства

Самый простой вариант - выложить исходники. Если твоя программа нужна кому-то еще, с определенной долей вероятности, найдутся желающие адаптировать и опакетить под конкретные дистрибутивы.

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

Для начала надо определиться с поддеживаемыми дистрибутивами. Притом не только с учетом форматов пакетов, но и с версиями базовых библиотек. Обычно выбирают версии Debian, Ubuntu, RHEL, которые еще не сняты с поддержки. Например, для Дебиана это версии >= 11. Далее собираем программу в deb, rpm со всеми нужными ей библиотеками в /opt/yourprogramm с учетом минимально поддерживаемых версий целевых дистрибутивов. Для любителей альтернативных пакетных менеджеров можно подготовить tar.gz.

Если же хочется совсем по правильному, то для сборки необходимо учитывать сборочные и рантайм окружения конкретных версий дистрибутивов. Дистрибутивные политики требуют использовать системные библиотеки. Поэтому обычно используют готовые инструменты типа pbuilder/sbuild, которые разворачивают в chroot’е чистое сборочное окружение нужной версии дистрибутива и собирают пакет в нем. Про это все придется читать в руководствах по опакечиванию и в политиках дистрибутивов.

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

дык и сделай пакеты для большинства дистрибутивов.

Ну, надо хотя бы один сделать для начала.

и потребителю не важно что у тебя федора али не федора - ему нужен пакет могущий установится на его дистрибутиве. вот и сделай под каждый дистрибутив.

Это я уже понял

вариант2: делаешь один «универсальный пакет» appimage flat snap и подобные. они правда требуют наличия запускалки для своего формата и она не везде есть… но кагбэ «универсальные» :)

Не… это уж совсем крайний случай :-) Попробую с пакетов начать.

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

Установка deb пакетов в федору чревата нехорошими последствиями

Это я уже запомнил

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

Для начала надо определиться с поддеживаемыми дистрибутивами.

ну, я хочу сделать deb и rpm и…пока хватит. Надо хоть с этим разобраться… хотя бы с одним.

Далее собираем программу в deb, rpm со всеми нужными ей библиотеками в /opt/yourprogramm

Вот насчет /opt/yourprogramm не очень понятно. Что это означает ?

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

Это пока явно не для меня

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

отсюда тег c++ надо убрать.

Убрал, если это так важно

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

кстати глянул в федору - пакета wxWidgets в федоре нет.
чё есть смотри сам https://packages.fedoraproject.org/search?query=wxWidgets
ты откудава брал имена пакетов ??
freetype есть. но мож тоже что не совпало

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

А можно это всё ручками создать или там запутаешься без автоматизации ?

Можно, более того, у тебя зато будет автоматизация потом, когда будет надо пересобрать.

Для RPM надо сделать файл .spec (руководств в интернете всё ещё много), параллельно собрать образ из устанавливаемых файлов (это можно bash-скриптом, например, сделать, потом проще будет обновлять) и всё это скормить команде rpmbuild.

Для DEB файлов конфигурации понадобится больше, главный из них DEBIAN/control. Поэтому, кстати, как программисту, RPM мне нравится больше.

Ну и не совсем по теме…

Разработка делалась на Windows

Это что-то такое между безалкогольным пивом и резиновой женщиной, на мой взгляд. Разработку кроссплатформенного кода как раз лучше вести на Linux, а винду дёргать только ради сборки и тестов Во-первых, так гораздо меньше шансов получить код, не работающий на «противоположной» ОС. Во-вторых, в линуксе есть божественный valgrind. В третьих, в линуксе гораздо проще притягивать сторонние библиотеки. (У меня есть ещё и в четвёртых, мне линукс просто нравится больше, но это вкусовщина, да.)

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

ну, я хочу сделать deb и rpm и…пока хватит. Надо хоть с этим разобраться… хотя бы с одним.

Deb и rpm - это форматы файлов пакетов. Грубо говоря, архивы, в которые ты запаковываешь свою программу. Программа может зависеть от системных библиотек, которые в разных версиях дистрибутива сильно отличаются. Допустим, собрал ты deb в убунте 24.10, а в нем исполняемый файл зависит от glibc 2.40. Всё, кирдык, он не запустится в убунте 20.04 и даже в 24.04. Пользователи этих дистров начинают думать о тебе плохо, хоть ты им и предоставил deb пакет. Напрашивается выход собрать твою программу под убунтой 22.04. Но и тут ждет сюрприз. Допустим, прога собрана с библиотекой libssl в 20.04 (в ней версия 1.1), а в убунте 24.04 уже несовместимая libssl 3. Опять будешь икать, несмотря на предоставленные пакеты. В линуксах с бинарной совместимостью всё плохо. Поэтому определившись в форматом пакета, нужно определиться какие версии дистрибутивов, использующих эти пакеты, ты готов поддерживать.

Вот насчет /opt/yourprogramm не очень понятно. Что это означает ?

Один из подходов как в винде, где прога ставится в свою папку (а ля C:\Program files\MyProg) со всеми потребными ей библиотеками. Т.е. ставишь свою прогу в /opt/<имя твоей проги>. По этому пути развертываешь свою иерархию bin, lib, share. Хотя, в общем случае, никаких ограничений там нет, хоть в одну папку складывай как в винде. Так ты минимально зависишь от системных библиотек.

Это пока явно не для меня

А придется. Соберешь ты свой софт под убунтой 2404, а тут я с дебианом 11 образца 21 года говорю что ничего не работает.

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

Для DEB файлов конфигурации понадобится больше, главный из них DEBIAN/control. Поэтому, кстати, как программисту, RPM мне нравится больше.

Для deb нужны как минимум debian/{changelog,control,rules}. Вообще, у дебиана более удачный формат пакетов, который можно собрать и изучать с помощью стандартных утилит, без hex-редакторов и пр, но совершенно наркоманская система сборки. В этом плане RPM с одним файлом приятней, да.

undef ★★★
()
Ответ на: комментарий от Ja-Ja-Hey-Ho

имя, сестра. скажи его имя, сестра !! :)
%тс% оперирует wxWidgets в качестве имени пакета.
в общем тс надо учить основам линукса а он не хочет.

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

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

Как это не прискорбно, но в линуксе так не бывает, ибо линукс — зоопарк.

Поэтому мне абсолютно не важно Fedora у меня или не Fedora - это чисто для экспериментов

Я тебе уже сказал, что это важно. Строить в федоре deb пакет — глупо нерационально.

Традиционный путь такой†:

  1. готовишь тарболл с исходниками и традиционным ./configure && make && sudo make install;
  2. делаешь пакет для своего дистрибутива.

Пользователи остальных дистрибутивов вольны опакечивать твою программу сами: тарболл в наличии.

Даже поддержка тарболла, который компилируется на популярных дистрах — уже немалая работа.

Можно написать spec, пригодный для построения пакета для нескольких дистров (магея, мандрива, суся, красная шапка, центось, …; у федоры есть даже сервис для этого, называется copr), но не факт что готовые пакеты будут удовлетворять всем требованиям дистров, т. к. требования часто разные. Федора, например, рекомендует использовать макрос %license, которого нет в других дистрах. Пакеты могут называться по-разному, поэтому в спеке при указании зависимостей приходится делать условные конструкции, и т. д. и т. п. Я к тому, что это тоже немаленькая работа. А это ещё только один rpm, не считая deb, PKGBUILD, и хз ещё кого.

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


† Я этот путь прошёл, жив. Возможно, есть более «современные» или лёгкие пути. В треде кто-то упоминал cmake и его cpack — можешь поэкспериментировать с ними. Но лично у меня воспоминания о cmake неприятные.

debugger ★★★★★
()

Пришёл решить весь тред касательно распространения софта в этих ваших люниксах. Чем больше перечисленных вариантов в наличии, тем лучше.

Отличные варианты:

  • архив с исходниками, внутри скрипт / файл настроек простой системы сборки, рядом лежит инструкция по компиляции и установке (и конфигурации, если присутствует);

  • архив с уже скомпилированным приложением;

  • appimage/runimage;

Вторичные варианты (т.е. те, которые никогда не должны быть единственным решением):

  • flatpak;

  • подключаемые репозитории для дистрибутивов;

Слабые, больные и беспомощные варианты:

  • snap;

  • deb/rpm архивы.

Bfgeshka ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.