Комментарии 22
4 открытых MC навели меня на мысльЧто такое MC?
Эмси, или MC (сокр. англ. Master of Ceremonies), в регги-культуре и хип-хопе — ведущий мероприятия, артист, в сопровождении электронной танцевальной музыки произносящий со сцены слова — заранее сочинённые или импровизированные, обычно в виде рэпа — чтобы раззадорить публику, а также представить диджея.
НЛО прилетело и опубликовало эту надпись здесь
Ещё спросите что такое NC и VC!
Что делать если у новичка linux без GUI?
Неправильный подход. Правильный — использовать 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 и т.д.
Поясняю, почему сборка deb'ки как архива с метаданными (то что вы делаете) — неправильно.
При использовании стандартных debian helper'ов заполняются поля dependencies для большинства языков программирования. Автоматически и правильно. Если вы пишите control полностью руками, то вы прибиваете зависимости руками, т.е. пересборкой пакета их не исправить.
Плюс ручная сборка дебки не позволяет адекватно встраиваться в существующие workflow — CI, публикация в репозитриях, автоматическая генерация версии из changelog'а, etc.
Что нужно, чтобы начать это делать? Написать простенький makefile в debian/rules, описывающий что надо сделать с вашими файлами, чтобы они стали пакетом, заполнить control и changelog. Ну и ещё по мелочи — compat, etc. Заодно можно воспользоваться бонусами debhelper'ов и переложить на них всю мутотень с init-скриптами, entry point'ами, shared-файлами, mime-типами, diversion и т.д.
Я бы не был столь категоричен. Организация workflow это другая совсем история. У нас пакет от сборщика до репозитория, проходит немалый путь. Публикуется и устанавливается на armhf платформу.
где здесь написано, что так делать нельзя?
Мне доводилось собирать пакеты используя dpkg-buildpackage. Но я не вижу ничего плохого, в ручном заполнении.
Особенно интересен момент с зависимостями. Почему их нельзя исправить пересобрав проект, переписав зависимости?
где здесь написано, что так делать нельзя?
Мне доводилось собирать пакеты используя dpkg-buildpackage. Но я не вижу ничего плохого, в ручном заполнении.
Особенно интересен момент с зависимостями. Почему их нельзя исправить пересобрав проект, переписав зависимости?
Ну, куча ненужной ручной работы же…
Сравни:
1) коммит в репо-> deb-src из этого (можно по hook-у) -> автоматическая параллельная сборка под 100500 архитектур с автоматическим проставлением зависимостей (а там могут быть разные версии зависимых пакетов, например)
2) твой воркфлоу.
Не имею ничего против, но это примерно, как чекинсталлом крафтить пакеты. но зачем? handmade — это круто, да :)
Сам на работе практикую первый способ. все довольны.
Сравни:
1) коммит в репо-> deb-src из этого (можно по hook-у) -> автоматическая параллельная сборка под 100500 архитектур с автоматическим проставлением зависимостей (а там могут быть разные версии зависимых пакетов, например)
2) твой воркфлоу.
Не имею ничего против, но это примерно, как чекинсталлом крафтить пакеты. но зачем? handmade — это круто, да :)
Сам на работе практикую первый способ. все довольны.
Я не против первого способа. Но почему-то люди боятся консоли (некоторые), для них слово «консоль» ассоциируется со словом «сложно». Для них она уже ушла как полезная.
А на счет сборки с помощь dpkg-buildpackage, я думал, думаю и возможно реализую через него, а пока что мне всё же проще так))
Тем более после создания первого пакета, остальные создаются просто изменением версии -> пару кликов -> пишем changelog -> пару кликов -> выход
Не вижу слишком больших сложностей.
А на счет сборки с помощь dpkg-buildpackage, я думал, думаю и возможно реализую через него, а пока что мне всё же проще так))
Тем более после создания первого пакета, остальные создаются просто изменением версии -> пару кликов -> пишем changelog -> пару кликов -> выход
Не вижу слишком больших сложностей.
Вот да, кстати.
Тем более, что debhelper всё равно ставится.
В принципе, сырцовые deb-пакеты вполне нормально могут поддерживать бинарные файлы — я для себя делал open-scad и KomodEdit таким образом.
И с писаниной получается попроще — всё разложено по своим файликам.
Описания, кстати, уже были на Хабре.
https://habrahabr.ru/post/282217/
https://habrahabr.ru/post/40183/
Тем более, что debhelper всё равно ставится.
В принципе, сырцовые deb-пакеты вполне нормально могут поддерживать бинарные файлы — я для себя делал open-scad и KomodEdit таким образом.
И с писаниной получается попроще — всё разложено по своим файликам.
Описания, кстати, уже были на Хабре.
https://habrahabr.ru/post/282217/
https://habrahabr.ru/post/40183/
не всегда пакет собирается с наличием сырцов.
К примеру. У человека нет доступа к репу в svn, но у него есть changelog, либы и бинарник (собственно именно для таких людей программа и писалась).
К примеру. У человека нет доступа к репу в svn, но у него есть changelog, либы и бинарник (собственно именно для таких людей программа и писалась).
«Сырцовый» dep-пакет — это не deb-пакет, собираемый из сырцов, а пакет, собираемый по схеме сырцового.
Т.е. сборка ведётся в каталоге debian, юзаются дебхелперовские файлы — а потом вся эта радость генерится э-ээ, debuld'ом, вроде.
Вот пример, собснна.
https://github.com/aso-c/deb-openscad
https://github.com/aso-c/dpkg-KomodoEdit
Т.е. сборка ведётся в каталоге debian, юзаются дебхелперовские файлы — а потом вся эта радость генерится э-ээ, debuld'ом, вроде.
Вот пример, собснна.
https://github.com/aso-c/deb-openscad
https://github.com/aso-c/dpkg-KomodoEdit
НЛО прилетело и опубликовало эту надпись здесь
mwambanatanga, извиняюсь. reame улетел в игнор. Как будет возможность запушу.
«Нет названия и описания пакета.» — А вот тут не понятно, о каком пакете Вы ведете речь?
«Нет названия и описания пакета.» — А вот тут не понятно, о каком пакете Вы ведете речь?
Как-то я себе слабо представляю человека, который может написать программу, но не сможет без GUI собрать пакет для неё.
Это элементарная ситуация. Даже не нужно моделировать. На тебе 4 проекта, 2 под контроллеры в IAR, 1 под embedded linux, и 1 под windows. Кроме того что нужно писать их, тебя ещё постоянно дёргает придурок плохой тестировщик, который вместо оформления issue просто идёт к тебя. Пара стажёров, которые в коде контроллера питания рисуют картинку на LCD. И ты не знаешь ни баша, ни как собирать пакет. Вот этому человеку проще покликать мышкой, запустить потом скрипт, который отправляет это всё на реп, и дальше разбираться со своими проблемами.
Скажете: «Ну это же гипотетически». Но вот у меня на работе таких людей хватает.
Скажете: «Ну это же гипотетически». Но вот у меня на работе таких людей хватает.
Тю, у меня deb-пакет одним скриптом собирается — это не проблема.
Вот сделал бы кто GUI для сборки PPA — и чтоб с регистрацией на ланчпаде, с генерацией и обменом ключей, с клонированием репы по разным дистрибутивам — тогда бы я действительно восхитился! )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Упрощать сложно — усложнять легко. GUI программа для создания deb-пакетов