Возможно, на меня снизойдет гнев эстетов 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 вопрос, ответ на который хотелось услышать от вас, дорогие Хабровчане и Хабровчанки. Как удобнее сделать сборщик:
Но на момент создания программы я не стал ломать себе голову (главное окно всегда можно переделать) и выбрал первый путь.
Программа на текущий момент использовалась только на нескольких машинах, использовалась небольшим количеством людей. Необходимость собирать source-пакеты отсутствовала поэтому и не была реализована. Находится она в исходниках на тут.
После запуска программы, мы можемнаслаждаться видеть стартовое окошко, предлагающее нам ввести путь к sysroot нашего пакета. Сборку самого sysroot в программу включать было (ИМХО) глупо, т. к. midnight commander или тот же thunar справятся с этим отлично сами.
Также если перейти в меню «Общее», и выбрать «Настройки», мы сможем:
Закончили настройки, выбрали папку — нажали продолжить — перешли к настоящимчудесам настройкам.
Имя пакета, версия и т. п. Всё это нам хорошо известно из Статьи, а вот тот момент, что программа запишет введённые здесь изменения в файл сразу по нажатию кнопки «Далее» стоит отметить сейчас. Не смотря на возможность вернуться назад, файл после нажатия «Далее» уже будет изменён!
Описывать, параметры я подробно не буду, они много где описаны, замечу только несколько удобных моментов в программе: в окне changelog'a, после примера, есть строчка где записаны имя, почта создателя пакета и время создания. Её удобно копировать и вставлять в конце свой записи в changelog.
В окне скриптов, по умолчанию стоят имена скриптов: preinst, postinst, prerm, postrm.
Если они уже лежат в каталоге sysroot/DEBIAN, то ничего не будет сделано, если же Вы захотите «притащить» их «снаружи», то выбранные файлы будут скопированы и переименованы, в зависимости от выбора поля.
В конце после успешной сборки пакета, пользователю предлагается использовать lintian для проверки.
Скажу честно, редко когда он полезен был, или пакет вообще не собирался, или если и писал lintian какие-либо ошибки, проблем с его установкой попросту не было…
Но всё же, приняв решение проверить пакет, ничего плохого не случится. В текущем окне будет показан вывод lintian при проверке созданного deb-пакета.
Label этот выделяемый, так что копируем warning или error и вперёд в поисковик искать как исправить эту проблему.
Я не претендую, что debCreator единственный хороший gui созбиратель пакетов. Также я не говорю, что в нём нету глюков и проблем. Однако, мне и людям, которые с ним уже работают, он сэкономил кучу времени, а ведь его ещё писать и писать…
Жду от прочитавших советов по реализации, и предложений по модернизации, в комментах или в issues.
Сюда будут вносится изменения, которые скоро будет реализованы:
С чего началось
Вдохновленный статьей о создании 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