Упрощать сложно — усложнять легко. GUI программа для создания deb-пакетов

    Возможно, на меня снизойдет гнев эстетов 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. Для контроля версий был призван выбран git.

    Очевидно, после прочтения статьи, что трудностей в написании кода возникнуть не должно, однако я сразу же выделил для себя основные этапы:

    1. Создаём виджеты для редактирования файлов
    2. Собираем виджеты до кучи в мастера создания пакетов
    3. Собираем пакет, проверив предварительно наличие программ

    Всё тривиально и просто, но остался до сих пор 1 вопрос, ответ на который хотелось услышать от вас, дорогие Хабровчане и Хабровчанки. Как удобнее сделать сборщик:

    1. Мастер сборки, по мотивам windows installerа (далее, далее, далее, готово)
    2. Мастер сборки с табами(сверху, снизу, слева, справа)

    Но на момент создания программы я не стал ломать себе голову (главное окно всегда можно переделать) и выбрал первый путь.

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

    Что получилось в итоге


    После запуска программы, мы можем наслаждаться видеть стартовое окошко, предлагающее нам ввести путь к sysroot нашего пакета. Сборку самого sysroot в программу включать было (ИМХО) глупо, т. к. midnight commander или тот же thunar справятся с этим отлично сами.



    Также если перейти в меню «Общее», и выбрать «Настройки», мы сможем:

    1. Задать путь для сохранения пакетов
    2. Кол-во всплывающих строк «Предыдущие каталоги»
    3. Задать для всех пакетов имя сборщика пакетов и e-mail

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

    Имя пакета, версия и т. п. Всё это нам хорошо известно из Статьи, а вот тот момент, что программа запишет введённые здесь изменения в файл сразу по нажатию кнопки «Далее» стоит отметить сейчас. Не смотря на возможность вернуться назад, файл после нажатия «Далее» уже будет изменён!

    Описывать, параметры я подробно не буду, они много где описаны, замечу только несколько удобных моментов в программе: в окне changelog'a, после примера, есть строчка где записаны имя, почта создателя пакета и время создания. Её удобно копировать и вставлять в конце свой записи в changelog.

    В окне скриптов, по умолчанию стоят имена скриптов: preinst, postinst, prerm, postrm.
    Если они уже лежат в каталоге sysroot/DEBIAN, то ничего не будет сделано, если же Вы захотите «притащить» их «снаружи», то выбранные файлы будут скопированы и переименованы, в зависимости от выбора поля.

    Окончание работы программы


    В конце после успешной сборки пакета, пользователю предлагается использовать lintian для проверки.

    Скажу честно, редко когда он полезен был, или пакет вообще не собирался, или если и писал lintian какие-либо ошибки, проблем с его установкой попросту не было…

    Но всё же, приняв решение проверить пакет, ничего плохого не случится. В текущем окне будет показан вывод lintian при проверке созданного deb-пакета.



    Label этот выделяемый, так что копируем warning или error и вперёд в поисковик искать как исправить эту проблему.

    Послесловие


    Я не претендую, что debCreator единственный хороший gui созбиратель пакетов. Также я не говорю, что в нём нету глюков и проблем. Однако, мне и людям, которые с ним уже работают, он сэкономил кучу времени, а ведь его ещё писать и писать…

    Жду от прочитавших советов по реализации, и предложений по модернизации, в комментах или в issues.

    TODO List


    Сюда будут вносится изменения, которые скоро будет реализованы:

    1. автоматическое заполнение confiles
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 22
    • –1
      4 открытых MC навели меня на мысль
      Что такое MC?
      • +12
        Эмси, или MC (сокр. англ. Master of Ceremonies), в регги-культуре и хип-хопе — ведущий мероприятия, артист, в сопровождении электронной танцевальной музыки произносящий со сцены слова — заранее сочинённые или импровизированные, обычно в виде рэпа — чтобы раззадорить публику, а также представить диджея.
        • +10
          Разумеется это это Menstrual Cycle. И 4 сразу, сам понимаешь, это жутко.
            • 0
              Ещё спросите что такое NC и VC!
            • +1
              Что делать если у новичка linux без GUI?
              • +1
                https://habrahabr.ru/post/78094/
                Берём статью на которую я приводил выше. И делаем всё ручками. Странный немного вопрос…
              • +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 и т.д.
                • 0
                  Я бы не был столь категоричен. Организация workflow это другая совсем история. У нас пакет от сборщика до репозитория, проходит немалый путь. Публикуется и устанавливается на armhf платформу.
                  где здесь написано, что так делать нельзя?
                  Мне доводилось собирать пакеты используя dpkg-buildpackage. Но я не вижу ничего плохого, в ручном заполнении.
                  Особенно интересен момент с зависимостями. Почему их нельзя исправить пересобрав проект, переписав зависимости?
                  • 0
                    Ну, куча ненужной ручной работы же…
                    Сравни:
                    1) коммит в репо-> deb-src из этого (можно по hook-у) -> автоматическая параллельная сборка под 100500 архитектур с автоматическим проставлением зависимостей (а там могут быть разные версии зависимых пакетов, например)
                    2) твой воркфлоу.

                    Не имею ничего против, но это примерно, как чекинсталлом крафтить пакеты. но зачем? handmade — это круто, да :)
                    Сам на работе практикую первый способ. все довольны.
                    • 0
                      Я не против первого способа. Но почему-то люди боятся консоли (некоторые), для них слово «консоль» ассоциируется со словом «сложно». Для них она уже ушла как полезная.

                      А на счет сборки с помощь dpkg-buildpackage, я думал, думаю и возможно реализую через него, а пока что мне всё же проще так))

                      Тем более после создания первого пакета, остальные создаются просто изменением версии -> пару кликов -> пишем changelog -> пару кликов -> выход

                      Не вижу слишком больших сложностей.
                      • 0
                        а мы ченджлог вообще не пишем. он из гит лога сам «магически» создается.

                        и еще по треду ниже ответ вам же:

                        ну из всего этого пакетить в деб надо же только «1 под embedded linux» :)
                        причем, выстрадать это надо только один раз при появлении проекта. дальше ci, все дела…

                        //ох уж эти *** ограничения…
                        • 0
                          у нас используется в основном svn, и пока что с CI всё плохо… вот и еб мучаемся
                  • 0
                    Вот да, кстати.
                    Тем более, что debhelper всё равно ставится.
                    В принципе, сырцовые deb-пакеты вполне нормально могут поддерживать бинарные файлы — я для себя делал open-scad и KomodEdit таким образом.
                    И с писаниной получается попроще — всё разложено по своим файликам.

                    Описания, кстати, уже были на Хабре.
                    https://habrahabr.ru/post/282217/
                    https://habrahabr.ru/post/40183/
                    • 0
                      не всегда пакет собирается с наличием сырцов.
                      К примеру. У человека нет доступа к репу в svn, но у него есть changelog, либы и бинарник (собственно именно для таких людей программа и писалась).
                      • 0
                        «Сырцовый» dep-пакет — это не deb-пакет, собираемый из сырцов, а пакет, собираемый по схеме сырцового.
                        Т.е. сборка ведётся в каталоге debian, юзаются дебхелперовские файлы — а потом вся эта радость генерится э-ээ, debuld'ом, вроде.
                        Вот пример, собснна.
                        https://github.com/aso-c/deb-openscad
                        https://github.com/aso-c/dpkg-KomodoEdit
                  • 0
                    Попытался собрать этой программой пакет с ней же. И не смог.

                    • Нигде в исходниках нет имени и эл почты автора. Да, конечно, можно использовать ник гитхаб-юзера или выковырять из истории коммитов, но должно быть ясно написано.
                    • Есть лицензия, но непонятно, кому принадлежат права на код.
                    • Нет названия и описания пакета.
                    • Нет инструкции для сборки. Непонятно, какие нужны зависимости.
                    • 0
                      mwambanatanga, извиняюсь. reame улетел в игнор. Как будет возможность запушу.
                      «Нет названия и описания пакета.» — А вот тут не понятно, о каком пакете Вы ведете речь?
                      • 0
                        о каком пакете Вы ведете речь?


                        О том, который Вы написали. Я его скомпилировал и натравил сам на себя — пускай делает бинарный деб-пакет для установки самого себя на другие машины.

                        Нигде среди сорцов нет официального названия софта. debCreator? DebCreator? debcreator?

                        Нигде среди сорцов не написано, что именно он делает.

                        reame улетел в игнор. Как будет возможность запушу.


                        А, ну ОК. Наверное, там и будет написана недостающая информация.
                    • 0
                      Как-то я себе слабо представляю человека, который может написать программу, но не сможет без GUI собрать пакет для неё.
                      • 0
                        Это элементарная ситуация. Даже не нужно моделировать. На тебе 4 проекта, 2 под контроллеры в IAR, 1 под embedded linux, и 1 под windows. Кроме того что нужно писать их, тебя ещё постоянно дёргает придурок плохой тестировщик, который вместо оформления issue просто идёт к тебя. Пара стажёров, которые в коде контроллера питания рисуют картинку на LCD. И ты не знаешь ни баша, ни как собирать пакет. Вот этому человеку проще покликать мышкой, запустить потом скрипт, который отправляет это всё на реп, и дальше разбираться со своими проблемами.

                        Скажете: «Ну это же гипотетически». Но вот у меня на работе таких людей хватает.
                      • +1

                        Тю, у меня deb-пакет одним скриптом собирается — это не проблема.


                        Вот сделал бы кто GUI для сборки PPA — и чтоб с регистрацией на ланчпаде, с генерацией и обменом ключей, с клонированием репы по разным дистрибутивам — тогда бы я действительно восхитился! )

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.