Возможно, на меня снизойдет гнев эстетов linux, vim, mc. Но скажу сразу, пользовались — знаем. Собирать deb-пакет, так для новичка, так что не будем усложнять ему жизнь изучением vim и mc, а а просто дадим дальше кликать мышкой. Кому интересен вопрос упрощения создания бинарных deb-пакетов и не боится собрать с помощью qtcreator'a сам, добро пожаловать под кат С чего началось
Вдохновленный статьей о создании deb-пакетов сел я собирать пакеты… После 10го пакета, признаться 4 открытых MC навели меня на мысль, что всё таки нужно gui инструмент. Конечно, тут же был установлен giftwrap, быстро заполнены первые страницы настройщика, и тут обнаруживается, что скрипты нужно опять таки тащить руками внутрь папки DEBIAN.
Я пришел в легкое недоумение. Почему нельзя было просто сделать возможность выбрать файл откуда угодно? Ну не беда, скопируем. Так, нужно прописать папки в DEBIAN/dirs. Стоп, а куда писать? Ну ни чего, у меня же есть vim и mc. Опять vim+mc для changelog…
Хватит. GiftWrap меня расстроил. Тогда мною было решено потратить вечерок и написать простую и при реализующую большие возможности чем GiftWrap утилиту. (Конечно же, лень делать это по старинке руками не повлияла на подобное решение).
Подготовка под эпичную музыку
В качестве среды разработки было решено использовать излюбленную мною среду QtCreator, и в качестве фрэймворка для гуи QtSdk 5.7. Для контроля версий был
Очевидно, после прочтения статьи, что трудностей в написании кода возникнуть не должно, однако я сразу же выделил для себя основные этапы:
- Создаём виджеты для редактирования файлов
- Собираем виджеты до кучи в мастера создания пакетов
- Собираем пакет, проверив предварительно наличие программ
Всё тривиально и просто, но остался до сих пор 1 вопрос, ответ на который хотелось услышать от вас, дорогие Хабровчане и Хабровчанки. Как удобнее сделать сборщик:
- Мастер сборки, по мотивам windows installerа (далее, далее, далее, готово)
- Мастер сборки с табами(сверху, снизу, слева, справа)
Но на момент создания программы я не стал ломать себе голову (главное окно всегда можно переделать) и выбрал первый путь.
Программа на текущий момент использовалась только на нескольких машинах, использовалась небольшим количеством людей. Необходимость собирать source-пакеты отсутствовала поэтому и не была реализована. Находится она в исходниках на тут.
Что получилось в итоге
После запуска программы, мы можем
Также если перейти в меню «Общее», и выбрать «Настройки», мы сможем:
- Задать путь для сохранения пакетов
- Кол-во всплывающих строк «Предыдущие каталоги»
- Задать для всех пакетов имя сборщика пакетов и e-mail
Закончили настройки, выбрали папку — нажали продолжить — перешли к настоящим
Имя пакета, версия и т. п. Всё это нам хорошо известно из Статьи, а вот тот момент, что программа запишет введённые здесь изменения в файл сразу по нажатию кнопки «Далее» стоит отметить сейчас. Не смотря на возможность вернуться назад, файл после нажатия «Далее» уже будет изменён!
Описывать, параметры я подробно не буду, они много где описаны, замечу только несколько удобных моментов в программе: в окне changelog'a, после примера, есть строчка где записаны имя, почта создателя пакета и время создания. Её удобно копировать и вставлять в конце свой записи в changelog.
В окне скриптов, по умолчанию стоят имена скриптов: preinst, postinst, prerm, postrm.
Если они уже лежат в каталоге sysroot/DEBIAN, то ничего не будет сделано, если же Вы захотите «притащить» их «снаружи», то выбранные файлы будут скопированы и переименованы, в зависимости от выбора поля.
Окончание работы программы
В конце после успешной сборки пакета, пользователю предлагается использовать lintian для проверки.
Скажу честно, редко когда он полезен был, или пакет вообще не собирался, или если и писал lintian какие-либо ошибки, проблем с его установкой попросту не было…
Но всё же, приняв решение проверить пакет, ничего плохого не случится. В текущем окне будет показан вывод lintian при проверке созданного deb-пакета.
Label этот выделяемый, так что копируем warning или error и вперёд в поисковик искать как исправить эту проблему.
Послесловие
Я не претендую, что debCreator единственный хороший gui созбиратель пакетов. Также я не говорю, что в нём нету глюков и проблем. Однако, мне и людям, которые с ним уже работают, он сэкономил кучу времени, а ведь его ещё писать и писать…
Жду от прочитавших советов по реализации, и предложений по модернизации, в комментах или в issues.
TODO List
Сюда будут вносится изменения, которые скоро будет реализованы:
- автоматическое заполнение confiles
Комментарии (22)
amarao
27.12.2016 19:53+9Неправильный подход. Правильный — использовать gbp buildpackage, или, хотя бы, dpkg-buildpackage. То есть поддерживать «source deb».
Поясняю, почему сборка deb'ки как архива с метаданными (то что вы делаете) — неправильно.
При использовании стандартных debian helper'ов заполняются поля dependencies для большинства языков программирования. Автоматически и правильно. Если вы пишите control полностью руками, то вы прибиваете зависимости руками, т.е. пересборкой пакета их не исправить.
Плюс ручная сборка дебки не позволяет адекватно встраиваться в существующие workflow — CI, публикация в репозитриях, автоматическая генерация версии из changelog'а, etc.
Что нужно, чтобы начать это делать? Написать простенький makefile в debian/rules, описывающий что надо сделать с вашими файлами, чтобы они стали пакетом, заполнить control и changelog. Ну и ещё по мелочи — compat, etc. Заодно можно воспользоваться бонусами debhelper'ов и переложить на них всю мутотень с init-скриптами, entry point'ами, shared-файлами, mime-типами, diversion и т.д.
skjame
28.12.2016 11:21Я бы не был столь категоричен. Организация workflow это другая совсем история. У нас пакет от сборщика до репозитория, проходит немалый путь. Публикуется и устанавливается на armhf платформу.
где здесь написано, что так делать нельзя?
Мне доводилось собирать пакеты используя dpkg-buildpackage. Но я не вижу ничего плохого, в ручном заполнении.
Особенно интересен момент с зависимостями. Почему их нельзя исправить пересобрав проект, переписав зависимости?aol-nnov
28.12.2016 12:22Ну, куча ненужной ручной работы же…
Сравни:
1) коммит в репо-> deb-src из этого (можно по hook-у) -> автоматическая параллельная сборка под 100500 архитектур с автоматическим проставлением зависимостей (а там могут быть разные версии зависимых пакетов, например)
2) твой воркфлоу.
Не имею ничего против, но это примерно, как чекинсталлом крафтить пакеты. но зачем? handmade — это круто, да :)
Сам на работе практикую первый способ. все довольны.skjame
28.12.2016 12:26Я не против первого способа. Но почему-то люди боятся консоли (некоторые), для них слово «консоль» ассоциируется со словом «сложно». Для них она уже ушла как полезная.
А на счет сборки с помощь dpkg-buildpackage, я думал, думаю и возможно реализую через него, а пока что мне всё же проще так))
Тем более после создания первого пакета, остальные создаются просто изменением версии -> пару кликов -> пишем changelog -> пару кликов -> выход
Не вижу слишком больших сложностей.aol-nnov
28.12.2016 12:29а мы ченджлог вообще не пишем. он из гит лога сам «магически» создается.
и еще по треду ниже ответ вам же:
ну из всего этого пакетить в деб надо же только «1 под embedded linux» :)
причем, выстрадать это надо только один раз при появлении проекта. дальше ci, все дела…
//ох уж эти *** ограничения…skjame
28.12.2016 12:33у нас используется в основном svn, и пока что с CI всё плохо… вот и
ебмучаемся
aso
28.12.2016 12:04Вот да, кстати.
Тем более, что debhelper всё равно ставится.
В принципе, сырцовые deb-пакеты вполне нормально могут поддерживать бинарные файлы — я для себя делал open-scad и KomodEdit таким образом.
И с писаниной получается попроще — всё разложено по своим файликам.
Описания, кстати, уже были на Хабре.
https://habrahabr.ru/post/282217/
https://habrahabr.ru/post/40183/skjame
28.12.2016 12:28не всегда пакет собирается с наличием сырцов.
К примеру. У человека нет доступа к репу в svn, но у него есть changelog, либы и бинарник (собственно именно для таких людей программа и писалась).aso
28.12.2016 12:55«Сырцовый» dep-пакет — это не deb-пакет, собираемый из сырцов, а пакет, собираемый по схеме сырцового.
Т.е. сборка ведётся в каталоге debian, юзаются дебхелперовские файлы — а потом вся эта радость генерится э-ээ, debuld'ом, вроде.
Вот пример, собснна.
https://github.com/aso-c/deb-openscad
https://github.com/aso-c/dpkg-KomodoEdit
mwambanatanga
28.12.2016 07:19Попытался собрать этой программой пакет с ней же. И не смог.
- Нигде в исходниках нет имени и эл почты автора. Да, конечно, можно использовать ник гитхаб-юзера или выковырять из истории коммитов, но должно быть ясно написано.
- Есть лицензия, но непонятно, кому принадлежат права на код.
- Нет названия и описания пакета.
- Нет инструкции для сборки. Непонятно, какие нужны зависимости.
skjame
28.12.2016 10:15mwambanatanga, извиняюсь. reame улетел в игнор. Как будет возможность запушу.
«Нет названия и описания пакета.» — А вот тут не понятно, о каком пакете Вы ведете речь?mwambanatanga
28.12.2016 10:22о каком пакете Вы ведете речь?
О том, который Вы написали. Я его скомпилировал и натравил сам на себя — пускай делает бинарный деб-пакет для установки самого себя на другие машины.
Нигде среди сорцов нет официального названия софта. debCreator? DebCreator? debcreator?
Нигде среди сорцов не написано, что именно он делает.
reame улетел в игнор. Как будет возможность запушу.
А, ну ОК. Наверное, там и будет написана недостающая информация.
ghostwolfling
28.12.2016 12:16Как-то я себе слабо представляю человека, который может написать программу, но не сможет без GUI собрать пакет для неё.
skjame
28.12.2016 12:20Это элементарная ситуация. Даже не нужно моделировать. На тебе 4 проекта, 2 под контроллеры в IAR, 1 под embedded linux, и 1 под windows. Кроме того что нужно писать их, тебя ещё постоянно дёргает
придурокплохой тестировщик, который вместо оформления issue просто идёт к тебя. Пара стажёров, которые в коде контроллера питания рисуют картинку на LCD. И ты не знаешь ни баша, ни как собирать пакет. Вот этому человеку проще покликать мышкой, запустить потом скрипт, который отправляет это всё на реп, и дальше разбираться со своими проблемами.
Скажете: «Ну это же гипотетически». Но вот у меня на работе таких людей хватает.
robux
28.12.2016 12:46+1Тю, у меня deb-пакет одним скриптом собирается — это не проблема.
Вот сделал бы кто GUI для сборки PPA — и чтоб с регистрацией на ланчпаде, с генерацией и обменом ключей, с клонированием репы по разным дистрибутивам — тогда бы я действительно восхитился! )
Varim
Jogger
Эмси, или MC (сокр. англ. Master of Ceremonies), в регги-культуре и хип-хопе — ведущий мероприятия, артист, в сопровождении электронной танцевальной музыки произносящий со сцены слова — заранее сочинённые или импровизированные, обычно в виде рэпа — чтобы раззадорить публику, а также представить диджея.
A-Stahl
Разумеется это это Menstrual Cycle. И 4 сразу, сам понимаешь, это жутко.
jok40
Midnight Commander.
varnav
Ещё спросите что такое NC и VC!