LINUX.ORG.RU

Цикл статей по сборке RPM и DEB пакетов


0

0

В интернете не так уж много информации относительно сборки пакетов. Конечно же существуют официальные документации по RPM и DEB, однако они довольно сухие, хотя и довольно полные. Мне захотелось написать список статей, описывающих основные подходы к сборке пакетов.

Конечно невозможно описать все особенности особенно при сборки пакетов Debian, где одно и тоже можно делать разными способами, однако я думаю, что эти статьи немного облегчат не такую уж и простую задачу сборки пакетов.

>>> Цикл статей

★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

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

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

>А результат - это улучшение здоровья,

только в ГТА ;) Хотя от проблем с психикой здорово помогает...

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

Особый смысл и состоит в том, чтобы пользоаться рекомендованными и предлагаемыми зависимостями не так тупо, как описано в статье.

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

Да нет же. Да, что что патчи идут в diff.gz, вот только

1. Их нужно создать 2. Их после распаковки дерева нужно применить.

Просто так патчи не применятся. Можно конечно хранить исправленное дерево в diff.gz, но это ведь не хорошо.

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

В статье написано

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

Так вот. не всё равно, ибо интерактивный выбор позволяет ставить только желанные пакеты а не только "либо всё, либо ничего".

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

> Про патчи всё очень просто - он один (тот что diff.gz) и агрегирует все остальные.

Что, слиты все вместе?? Какой кошмар.. А как настраивать приоритет (очередность) установки? Как включать/исключать конкретные патчи - из spec'а (ну то есть как там аналог в дебиане называется). Как сделать так, чтобы в завимимостей от опций сборки - ну там rpmbuild --rebuild myprog.rpm --with-feature1 --without-feature2 не только опции для configure менялись, но и патчи накладывались/не накладывались - штатными средствами?

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

Что идет в diff.gz? Идет каталог debian. В нём идут файлы (control, rules etc) и в каталоге patches идут патчи 01_blblbla.dpatch 02_ооо.dpatch...

После того как мы исходник распаковываем либо apt-get source, либо dpkg- source -x на оригинальный исходник накладывается патч diff.gz и в дереве появляется папка debian. А когда мы запускаем сборку пакета на него уже накладываются патчи, которые лежат в каталоге patches. Что их нужно накладывать описывается в rules.

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

Никак. Дебиан система для пользователей и админов, а не тестеров.

anonymous
()
Ответ на: комментарий от Deady

И тебе за это зачот. Все "несоберусь" дебку собрать.

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

> Ой ли? Соизвольте доказать, что ли, ибо это, мягко говоря, не так.

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

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

Нет, конечно же они идут не все вместе, вернее у нерадивых девелоперов всё идет вообще без патчей (и без diff.gz тоже), правят дерево и поехали. А порядок регулируется в файле 00list.

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

Не понял, а зачем создавать патч? Типа соблюдать правила хорошего тона, или с прицелом на помещение в главное хранилище?

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

>А у нетерминированных автоматов есть проблема - никогда нельзя быть уверенным, что проверены все переходы.

А в чём заключается проверка всех переходов? Если элемент НДА (недет. авт.) представляет из себя просой текстовой процессор, то вся проверка заключается только в том, чтобы проверить ег на любом типе данных. А текстовой процессор - ДА. А так как ДА надёжен, что и НДА надёжен, ибо В НДА все потоки - детерминированы. Значит и НДА становится ДА, как только все потоки становятся детерминированы.

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

И для того и для того. Обычно мы же исправляем чужие пакеты и от версии к версии этот патч может быть уже не нужен.

И такой например пример. Был пакет aaa_1.0. в нем кто-то одно поправил, второй другое, третий третье. Все хорошо, все без патчей. Но вот вышел 1.1 и хочется перенести то что понаделали в новый пакет. Патчей нет, те кто в пакетах копался либо ничего не помнят, либо тоже их уже нет. Или и то и другое. А если сделать diff между 1.0 и 1.1 то все что было проделано (тремя людьми) спрячется за официальными изменениями.

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

Проще говоря, НДА с ДП есть ДА.

anonymous
()
Ответ на: комментарий от Tigro

>И для того и для того. Обычно мы же исправляем чужие пакеты и от версии к версии этот патч может быть уже не нужен.

"Для того", имхо, это не нужно, а вот "и для того" да, сложно, но если юзер захотел сувать пакет в главное хранилище, то трудности с пакетизацией - лишь малая доля проблем. Работать с одним патчем проще при изучении ошибок.

>А если сделать diff между 1.0 и 1.1 то все что было проделано (тремя людьми) спрячется за официальными изменениями.

И это плохо?

В дебе как - имеем 1.1.orig и патчи. Вот эти патчи из 1.0, приглаженные к 1.1, и будут в .diff.gz.

anonymous
()
Ответ на: комментарий от Tigro

> вернее у нерадивых девелоперов всё идет вообще без патчей (и без diff.gz тоже), правят дерево и поехали.

Злобно..

> А порядок регулируется в файле 00list.

Во внешнем файле, отдельно от основных инструкций сборки? А как тогда включать/отключать патчи?

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

В предпоследней статье написано по этому поводу.

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

Мы похоже друг друга не понимаем. Делать можно все что угодно. Можно говорить и make install.

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

> Для результата Камасутра не очень нужна.

Зависит от того, какое явление рассматривать в качестве результата, не так ли?

Gharik
()

в gentoo: ebuild <blabla.ebuild> rpm

ovod
()
Ответ на: комментарий от Tigro

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

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

подскажите аналог mock для OpenSuSE чтобы создать buildroot, где-то видел целый pdf по этому поводу, а вот как собрался собрать, найти не могу

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

>возможность сделать одно и тоже разными способами говорит о избыточности инструментария, его неоправданной сложности и, как следствие, высокой вероятности ошибок

Забрать кусок текста в буфер: "Копировать" из контекстного меню, Ctrl+C, Ctrl+Insert.

Избыточный инструментарий неоправданной сложности, не иначе....

MYMUR ★★★★
()

Пиздец

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

> возможность сделать одно и тоже разными способами говорит о избыточности инструментария, его неоправданной сложности и, как следствие, высокой вероятности ошибок

Гы-гы-гы :-)

"Правило Многообразия: Отвергайте все утверждения об «единственно правильном пути»" (C) http://ru.wikipedia.org/wiki/Unix_way

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

> А у нетерминированных автоматов есть проблема - никогда нельзя быть уверенным, что проверены все переходы.

Зато недетерминированные автоматы имеют возможность оптимизировать стоимость достижения цели в зависимости от выбранных критериев.

> А у нетерминированных автоматов есть проблема - никогда нельзя быть уверенным, что проверены все переходы.

4.2

> Далее, реализация недетерминированных автоматов базируется на детерминируемых автоматах, при этом общая сложность детерминированного автомата увеличивается.

А эта фраза вообще сломала мой моск :-)

> который еще и в силу своего недетерминизма хуже оттестирован.

Вообще говоря, корректность автоматов при современном состоянии науки и техники не тестируется, а доказывается. Так что, аргумент мимо кассы.

А вообще, советую осознать разницу между абстрактной спецификацией и способами ее реализации.

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

> подскажите аналог mock для OpenSuSE чтобы создать buildroot, где-то видел целый pdf по этому поводу, а вот как собрался собрать, найти не могу

PDF c SUSE Package Conventions переехал в вики: http://en.opensuse.org/Packaging/SUSE_Package_Conventions

Что такое mock - не знаю, но для сборки в chroot в openSUSE есть пакет build.

i
()
Ответ на: комментарий от anonymous

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

anonymous
()

А где бы найти описание как заворачивать в deb программы на скриптовых ЯП, например питон.

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

Как и все остальные программы. В чём проблема?

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

Это и называется красноглазием (ничего личного%) - когда процесс становится важнее результата;)

svu ★★★★★
()

Привет Тигра! И сайтик свой новый попеарил заодно, молодец :)

kpblca
()
Ответ на: комментарий от svu

Низкий же тогда КПД ваших процессов... ;)

anonymous
()
Ответ на: комментарий от svu

> ОЧЕВИДНО ЖЕ, рождение ребенка. А Вы что подумали?;)

Судя по тому, что Россия по населению еще не обогнала, скажем, Китай или Индию, таки нет. :)

kda ★★★★★
()

Привет Тигро! Репозисторий у тебя конечно хороший, но если заменить cвои gstreamer plugins с livna на те что идут c tigro то чего-то много чего перестает играть. Приходится при апдейтах следить чтобы multimedia барахло шло только с Ливны.

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

> что же это за барахло libexpatso1?

XML парсер.. Похоже в новой опере часть настроек будет храниться в xml.

anonymous
()

Спасибо!

Deleted
()

> Deb-пакет представляет собой gzip-архив, а также скрипты и дополнительные файлы.

Не gzip-архив, а ar-архив. gzip - не архиватор, а компрессор, архивы создавать он не может.

anonymous
()
Ответ на: комментарий от Tigro

Если честно, то нихера нового, по сравнению с официальными руководствами ты не раскрыл. Лучше бы написал побольше про файлы rules, как зависимости прописать(не ручками, а автоматически) и т.п. Короче - фтопку.

anonymous
()

Не понимаю чем статья по сборке deb пакета лучше официальной документации по сборке deb пакетов

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

> Не понимаю чем статья по сборке deb пакета лучше официальной документации по сборке deb пакетов

Основное там - статьи по сборке rpm. Смысл статьей по сборке deb - открыть глаза людям на крайнюю убогость этого процесса по сравнению со сборкой rpm, а то некоторые питают какие-то иллюзии...

anonymous
()
Ответ на: комментарий от svu

> ОЧЕВИДНО ЖЕ, рождение ребенка. А Вы что подумали?;)

Так всё в данной цепочке от самой задумки и вплоть до получения результата должно приносить удовольствие, рекомендовано ведущими мозговедами ;)

Gharik
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.