Сборка пакетов в Mandriva (поверхностный вопрос)

[-sanches-]

Доброго времени суток!
Хочу разобраться с сабже при условии, что подобным я занимался только на deb дистрибутивах.
Что есть в deb:
1. В deb есть понятие "дебианизация исходников"
2. В deb есть возможность стащить исходники из репозитория тестируемой ветки
3. Установка необходимых зависимостей для сборки из исходников одной командой
4. Сборка исходников в deb пакет.

Может кто -нибудь прокомментировать эти пункты, но применительно к Mandriva?

[diesel]

i	Уведомление от модератора
	переношу в мандриву

[akdengi]

Доброго времени суток!
Хочу разобраться с сабже при условии, что подобным я занимался только на deb дистрибутивах.
Что есть в deb:
1. В deb есть понятие "дебианизация исходников"
2. В deb есть возможность стащить исходники из репозитория тестируемой ветки
3. Установка необходимых зависимостей для сборки из исходников одной командой
4. Сборка исходников в deb пакет.

Может кто -нибудь прокомментировать эти пункты, но применительно к Mandriva?

Стандартное руководство по RPM от RedHat и вперед...
То есть в Mandriva (за исключением специфических макросов в spec) все по стандарту. Часть есть на ВиКи (http://wiki.mandriva.com/ru/Development/Howto/RPM)

[drBatty]

1. В deb есть понятие "дебианизация исходников"
2. В deb есть возможность стащить исходники из репозитория тестируемой ветки
3. Установка необходимых зависимостей для сборки из исходников одной командой
4. Сборка исходников в deb пакет.

взгляд "тупого безмозглова ламера" ;) :
1) тут приходится просто собирать "как есть", причём не всегда получается. и лучше так не делать.
2) тут есть main, а есть PLF, что-то вроде тестовой. если подключить - глюки и косяки гарантированы, однако если не подключать, то многого не хватает.
3) urpmi. только из пакетов. из исходников надо ручками... в большинстве случаев...
4) checkinstall -R, конечно получается родной RPM пакет.

ЗЫЖ ну а ещё из минусов - заходишь на сайт девелоперов - у них и deb есть, и для suse есть, и для чего хочешь есть, а для Mandriva нету... Лично моё мнение и мой не слишком большой(с 2007) опыт...

[akdengi]

1. В deb есть понятие "дебианизация исходников"
2. В deb есть возможность стащить исходники из репозитория тестируемой ветки
3. Установка необходимых зависимостей для сборки из исходников одной командой
4. Сборка исходников в deb пакет.

взгляд "тупого безмозглова ламера" ;) :
1) тут приходится просто собирать "как есть", причём не всегда получается. и лучше так не делать.
2) тут есть main, а есть PLF, что-то вроде тестовой. если подключить - глюки и косяки гарантированы, однако если не подключать, то многого не хватает.
3) urpmi. только из пакетов. из исходников надо ручками... в большинстве случаев...
4) checkinstall -R, конечно получается родной RPM пакет.

ЗЫЖ ну а ещё из минусов - заходишь на сайт девелоперов - у них и deb есть, и для suse есть, и для чего хочешь есть, а для Mandriva нету... Лично моё мнение и мой не слишком большой(с 2007) опыт...

Пакеты собирать не так сложно как кажется а один раз написанный спек живет иногда несколько лет - вопрос в ресурсах. Нет пакета - станьте его майнтейнером. Репозиторий и дорогу в кукер а далее в Мандрива дадим. Так что ворчать смысла не вижу - хотя бы пересобрать пакеты под новую версию и то помощь например будет

[drBatty]

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

тоже верно...

[SinClaus]

Пакеты собирать не так сложно как кажется а один раз написанный спек живет иногда несколько лет - вопрос в ресурсах. Нет пакета - станьте его майнтейнером. Репозиторий и дорогу в кукер а далее в Мандрива дадим. Так что ворчать смысла не вижу - хотя бы пересобрать пакеты под новую версию и то помощь например будет

Наконец-то понял, зачем собирать rpm на своей машине, если программа просто устанавливается... Учту.

[akdengi]

Пакеты собирать не так сложно как кажется а один раз написанный спек живет иногда несколько лет - вопрос в ресурсах. Нет пакета - станьте его майнтейнером. Репозиторий и дорогу в кукер а далее в Мандрива дадим. Так что ворчать смысла не вижу - хотя бы пересобрать пакеты под новую версию и то помощь например будет

Наконец-то понял, зачем собирать rpm на своей машине, если программа просто устанавливается... Учту.

Это вообще то был тонкий намек помочь в сборке пакетов А то мне поддерживать два релиза и две архитектуры сложновато будет А так с удовольствием отдам сборку 64 разрядных пакетов из EduMandriva в хорошие руки.

[drBatty]

Наконец-то понял, зачем собирать rpm на своей машине, если программа просто устанавливается.

эх... если бы она "просто устанавливалась"... вот aMule просто устанавливается, и пишет - версия слишком стара. А новой пока нет, т.е. есть, но только в исходниках.

Это вообще то был тонкий намек помочь в сборке пакетов smile.gif А то мне поддерживать два релиза и две архитектуры сложновато будет sad.gif А так с удовольствием отдам сборку 64 разрядных пакетов из EduMandriva в хорошие руки.

это я понял. но во первых я ещё не все доки прочитал на эту тему, а позорится не хочется
а во вторых - 64 у меня нету. все по 32...

[SinClaus]

Это вообще то был тонкий намек помочь в сборке пакетов А то мне поддерживать два релиза и две архитектуры сложновато будет А так с удовольствием отдам сборку 64 разрядных пакетов из EduMandriva в хорошие руки.

Я вообще-то тоже ретроград - т.е. попросту не вижу пока смысла переходить на 64-разрядную ось. И с AMD в этой области пару раз обжегшись не связываюсь. Вот бит-слайсовые процессоры у них были отличные...

[akdengi]

Это вообще то был тонкий намек помочь в сборке пакетов А то мне поддерживать два релиза и две архитектуры сложновато будет А так с удовольствием отдам сборку 64 разрядных пакетов из EduMandriva в хорошие руки.

Я вообще-то тоже ретроград - т.е. попросту не вижу пока смысла переходить на 64-разрядную ось. И с AMD в этой области пару раз обжегшись не связываюсь. Вот бит-слайсовые процессоры у них были отличные...

Я тоже не вижу - но народ "просит"

[olelukoie]

Это вообще то был тонкий намек помочь в сборке пакетов А то мне поддерживать два релиза и две архитектуры сложновато будет А так с удовольствием отдам сборку 64 разрядных пакетов из EduMandriva в хорошие руки.

Я вообще-то тоже ретроград - т.е. попросту не вижу пока смысла переходить на 64-разрядную ось. И с AMD в этой области пару раз обжегшись не связываюсь. Вот бит-слайсовые процессоры у них были отличные...

Для того, чтобы использовать 64-битную ось, вовсе не требуется покупать процессор AMD. У меня Core 2 Duo, и я использую архитектуру x86_64 без каких-либо проблем, поскольку имею возможность запускать и 32-битные, и 64-битные приложения. А смысл - 64-битки, по моим личным наблюдениям и тестам, работают немного стабильнее и, главное, шустрее, чем 32-битки на том же железе.
Но пакеты собирать не смогу, поскольку использую кукер (вернее, смогу, но только для кукера, а не для стабильного дистра).

[SinClaus]

"Стабильнее" - понятие относительное. У меня рабочая машина под иксами уже около месяца без перегрузок. При всех моих издевательствах над ней . Это как - стабильно? Мандрива 2008.1 х86, Core 2 Duo, 4 Gb RAM.

[olelukoie]

"Стабильнее" - понятие относительное.

Конечно относительное. Поэтому я и написал "по моим личным наблюдениям", т.е. я говорю о тех приложениях, которые использую я, и о том режиме работы, который использую я (как минимум 3-5 циклов включения/выключения/перезагрузки в день). И в последнее время некоторые производители ПО уже отказались от выпуска 32-битных версий для Linux (Autodesk Maya, например). Так что окончательный переход индустрии на 64 бита уже не за горами. Думаю, что это вопрос 2-3 лет, особенно учитывая, что этот переход идет не только в мире *NIX, но и в мире Win (2008 R2 тоже существует только в 64-битном варианте). Кроме того здесь может сыграть свою роль экономический кризис, и производители железа и, особенно, софта могут отказаться от поддержки 32 бит с целью удешевления производства, снижения "числа транзисторов" и сокращения затрат на поддержку нескольких версий одной и той же софтины. Ну и еще одна причина моего выбора: поскольку Linux для меня - исключительно хобби (работаю я в основном под виндой), мне в первую очередь интересны именно новинки (bleeding edge ), даже в ущерб всему остальному. Потому я на своих компах и не использую стабильных дистров.

Сорри за оффтоп.

[akdengi]

"Стабильнее" - понятие относительное.

Конечно относительное. Поэтому я и написал "по моим личным наблюдениям", т.е. я говорю о тех приложениях, которые использую я, и о том режиме работы, который использую я (как минимум 3-5 циклов включения/выключения/перезагрузки в день). И в последнее время некоторые производители ПО уже отказались от выпуска 32-битных версий для Linux (Autodesk Maya, например). Так что окончательный переход индустрии на 64 бита уже не за горами. Думаю, что это вопрос 2-3 лет, особенно учитывая, что этот переход идет не только в мире *NIX, но и в мире Win (2008 R2 тоже существует только в 64-битном варианте). Кроме того здесь может сыграть свою роль экономический кризис, и производители железа и, особенно, софта могут отказаться от поддержки 32 бит с целью удешевления производства, снижения "числа транзисторов" и сокращения затрат на поддержку нескольких версий одной и той же софтины. Ну и еще одна причина моего выбора: поскольку Linux для меня - исключительно хобби (работаю я в основном под виндой), мне в первую очередь интересны именно новинки (bleeding edge ), даже в ущерб всему остальному. Потому я на своих компах и не использую стабильных дистров.

Сорри за оффтоп.

Ну это и понятно - придется ставить вторую 64 битную систему для сборки...

[belui]

А как устанавливать программу из архива tar.gz ,и можно ли из него собрать rpm-пакет?

[omerta13]

А как устанавливать программу из архива tar.gz ,и можно ли из него собрать rpm-пакет?

Программа устанавливается предварительной компиляцией, затем командой make install. Установка из tar.gz есть наибольшее зло.
Собрать пакет можно, но для этого нужно иметь определённые навыки.

[drBatty]

Собрать пакет можно, но для этого нужно иметь определённые навыки.

не можно, а НУЖНО!
Установка программ из исходников

ЗЫЖ я про Mandriva, может в кубунтах/убунтах по другому.

ЗЗЫЖ если вы не можете собрать пакет, то и tar.bz2 распаковывать не стоит... ИМХО

[SinClaus]

Программа устанавливается предварительной компиляцией, затем командой make install. Установка из tar.gz есть наибольшее зло.

Не понял... Высказывание в стиле дядюшки Билла Может оно в Москве и так, а при работе - вовсе даже наоборот.
Например - мы долго убеждаем Хироюки Ямамото внести какую-то фичу в Сильфид, в конце концов объединенными усилиями выпускается RC, а затем и релиз с крайне необходимыми свойствами. Что, ждать пока добрые дяди соберут пакет для Мандривы? Так ведь фигу - 2.6.0 собрали только для 2009.1, а тем кто сидит в рабочей и отлаженной 2008.1 что, лапу сосать?
Xneur вообще в дистрибутиве отсутствует, с Пиджином - та же ситуация что с Сильфидом.

[Pulfer]

а тем кто сидит в рабочей и отлаженной 2008.1 что, лапу сосать?

Можно пойти на форум MIB и попросить, чтобы собрали пакет. Сейчас поддерживаются 2008.1 & 2009.1, 32 и 64 бита.

[akdengi]

а тем кто сидит в рабочей и отлаженной 2008.1 что, лапу сосать?

Можно пойти на форум MIB и попросить, чтобы собрали пакет. Сейчас поддерживаются 2008.1 & 2009.1, 32 и 64 бита.

А в чем проблема пересобрать самим из сурсов от старшей версии? Если что-то не идет можно тут например попросить, поправим spec. Просто поддерживать много архитектур накладно - я например максимум смогу поддерживать два релиза. Тут проблема достаточно серьезная так как не хватает майнтейнеров и поддержки contrib вообще год идет...

Специально на qa.edumandriva.ru и на za1raz есть разделы где можно попросить собрать пакет. Не факт что все сделаем, но некоторые вещи можно и дособрать.

[omerta13]

Программа устанавливается предварительной компиляцией, затем командой make install. Установка из tar.gz есть наибольшее зло.

Не понял... Высказывание в стиле дядюшки Билла Может оно в Москве и так, а при работе - вовсе даже наоборот.

Я могу пояснить, почему tar.gz - есть зло для пакетных дистрибутивов. Ведь при установке программ из тарболлов легко получить систему, состояние которой перестаёт быть согласованным. Менеджер пакетов говорит, что в системе установлен пакет одной версии, на самом деле - стоит вообще другой, который мы поставили из тарболлов. В итоге, если сюда ещё прибавить какие-либо зависимости от этого пакета, получим полную жопу...
Тогда уж действительно посвятите вопросу сборки backports 30 минут своего свободного времени.

P. S.: причём здесь Москва?

[SinClaus]

На P.S. - отсюда почти не видно разницы
Pulfer, в моей системе нужно сделать четыре команды (включая wget), что бы собрать и установить (апгрейдить) нужную программу. Зачем мне куда-то идти и что-то просить?
akdengi, зачем усложнять? У меня постоянно лежит исходник любой программы, изредка приходится его править самому, либо патчить, и пересобирать.
omerta13, тогда нужно говорить о квалификации пользователя, а не о пакетности дистрибутива. Я все равно манагеру не верю и не злоупотребляю, но ключем --force пользуюсь.
Поучаствовать в сборке backports не отказываюсь, только вот интересуют ли кого rpm для 2008.1?

[akdengi]

Поучаствовать в сборке backports не отказываюсь, только вот интересуют ли кого rpm для 2008.1?

Интересуют, так как у меня сборочных уже не осталось для этой версии - банально нет места на машине...

[omerta13]

Поучаствовать в сборке backports не отказываюсь, только вот интересуют ли кого rpm для 2008.1?

Интересуют, так как у меня сборочных уже не осталось для этой версии - банально нет места на машине...

Короче надо силами коммунити писать руководство мейнтейнера. Необходимость в бумажке становится с каждым днём всё очевиднее. Нужно наконец собраться, да написать совместными усилиями. Особенно полезно будет прочувствовать на себе все подводные камни и предостеречь новичков. В принципе есть уже документ... http://wiki.mandriva.com/ru/Development/Howto/RPM надо его доперевести и возможно откорректировать. Я перевёл часть, но некоторые моменты для меня не совсем понятны, поскольку я не мейнтейнер. Возможно, пока

[olelukoie]

Короче надо силами коммунити писать руководство мейнтейнера. Необходимость в бумажке становится с каждым днём всё очевиднее. Нужно наконец собраться, да написать совместными усилиями. Особенно полезно будет прочувствовать на себе все подводные камни и предостеречь новичков. В принципе есть уже документ... http://wiki.mandriva.com/ru/Development/Howto/RPM надо его доперевести и возможно откорректировать. Я перевёл часть, но некоторые моменты для меня не совсем понятны, поскольку я не мейнтейнер. Возможно, пока

Давайте сюда, что именно не понятно, бум разбираться.

[omerta13]

Короче надо силами коммунити писать руководство мейнтейнера. Необходимость в бумажке становится с каждым днём всё очевиднее. Нужно наконец собраться, да написать совместными усилиями. Особенно полезно будет прочувствовать на себе все подводные камни и предостеречь новичков. В принципе есть уже документ... http://wiki.mandriva.com/ru/Development/Howto/RPM надо его доперевести и возможно откорректировать. Я перевёл часть, но некоторые моменты для меня не совсем понятны, поскольку я не мейнтейнер. Возможно, пока

Давайте сюда, что именно не понятно, бум разбираться.

Т. к. документ довольно большой, предлагаю разбирать по разделам. Давайте начнём с раздела http://wiki.mandriva.com/ru/%D0%9E%D1%81%D...8_.28install.29
Я его перевёл, но возможно из-за перевода материал потерял ясность. Я и сам местами не совсем понимаю о чём говорится. В разделе сверху идёт кусок перевода, ниже - кусок оригинала.

[olelukoie]

Давайте начнём с раздела http://wiki.mandriva.com/ru/%D0%9E%D1%81%D...8_.28install.29
Я его перевёл, но возможно из-за перевода материал потерял ясность. Я и сам местами не совсем понимаю о чём говорится. В разделе сверху идёт кусок перевода, ниже - кусок оригинала.

Сперва одно замечание: simulation installation dir - прилагательное simulation относится к существительному installation, т.е. речь идет о каталоге, в котором производится имитация установки. Я бы использовал просто "временный каталог" или "временная директория", а если более развернуто, то "директория, в которой (или в которую) производится имитация установки".
Суть ее в том, что при выполнении раздела %install автоматически создается эта самая "simulation installation" директория (следовательно, у пользователя, собирающего пакет, должны быть соотв. права на запись), назначается временным корневым каталогом (при помощи prefix или DESTDIR) и в нее устанавливается программа (при помощи стандартной команды make install с соответствующими параметрами). Путь к этой директории задается в spec-файле в строке BuildRoot, а получить этот путь для своих целей в этом же spec-файле можно с помощью $RPM_BUILD_ROOT. Самое простое содержание раздела %instsall выглядит как одна команда make DESTDIR=$RPM_BUILD_ROOT install или как вызов макроса %makeinstall.

"Странная" фраза "It is the same for old strip $RPM_BUILD_ROOT%{_bindir}/* || : lines: they have to be removed " относится к тому, что выполнять strip вручную не требуется, это делается атоматически при упаковке бинарного rpm, аналогично использованию сжатия lzma для man- и info-страниц.

А так в целом все правильно, кроме некоторых шероховатостей русского текста (кальки с английского, опечатки) . Например, Ваше "Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников." выглядит так, как будто "симулируемый установочный каталог" предназначен для "autoconf-исходников", хотя речь идет о том, что в эту директорию устанавливаются бинарники, собранные из исходников, сконфигурированных с помощью autoconf. Если для конфигурирования исходников использовалось что-то другое (не autoconf), то эта команда может быть некорректной и либо не установит вообще ничего, либо установит, но не туда или не так. Типичный пример - программы, исходники которых конфигурируются с помощью cmake или вообще не трубуют конфигурирования.

ЗЫ Вообще-то я рассчитывал на более конкретные вопросы, чем просто "я перевел, но не очень понял, что" .

[akdengi]

Давайте начнём с раздела http://wiki.mandriva.com/ru/%D0%9E%D1%81%D...8_.28install.29
Я его перевёл, но возможно из-за перевода материал потерял ясность. Я и сам местами не совсем понимаю о чём говорится. В разделе сверху идёт кусок перевода, ниже - кусок оригинала.

Сперва одно замечание: simulation installation dir - прилагательное simulation относится к существительному installation, т.е. речь идет о каталоге, в котором производится имитация установки. Я бы использовал просто "временный каталог" или "временная директория", а если более развернуто, то "директория, в которой (или в которую) производится имитация установки".
Суть ее в том, что при выполнении раздела %install автоматически создается эта самая "simulation installation" директория (следовательно, у пользователя, собирающего пакет, должны быть соотв. права на запись), назначается временным корневым каталогом (при помощи prefix или DESTDIR) и в нее устанавливается программа (при помощи стандартной команды make install с соответствующими параметрами). Путь к этой директории задается в spec-файле в строке BuildRoot, а получить этот путь для своих целей в этом же spec-файле можно с помощью $RPM_BUILD_ROOT. Самое простое содержание раздела %instsall выглядит как одна команда make DESTDIR=$RPM_BUILD_ROOT install или как вызов макроса %makeinstall.

"Странная" фраза "It is the same for old strip $RPM_BUILD_ROOT%{_bindir}/* || : lines: they have to be removed " относится к тому, что выполнять strip вручную не требуется, это делается атоматически при упаковке бинарного rpm, аналогично использованию сжатия lzma для man- и info-страниц.

А так в целом все правильно, кроме некоторых шероховатостей русского текста (кальки с английского, опечатки) . Например, Ваше "Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников." выглядит так, как будто "симулируемый установочный каталог" предназначен для "autoconf-исходников", хотя речь идет о том, что в эту директорию устанавливаются бинарники, собранные из исходников, сконфигурированных с помощью autoconf. Если для конфигурирования исходников использовалось что-то другое (не autoconf), то эта команда может быть некорректной и либо не установит вообще ничего, либо установит, но не туда или не так. Типичный пример - программы, исходники которых конфигурируются с помощью cmake или вообще не трубуют конфигурирования.

ЗЫ Вообще-то я рассчитывал на более конкретные вопросы, чем просто "я перевел, но не очень понял, что" .

Конкретика должна быть вида: как написать spec для того-то, того-то..
И отдельные части - ярлыки, MIME-типы.
Как вариант -
1. spec без сборки (доп. пакеты, java программы, бинарные пакеты - то есть где не нужно собирать).
2. spec для configure && make && make install
3. spec для qmake
4. spec для python прог

и .т.п.