Ubuntu Lucid принимает на вооружение новый формат пакетов исходного кода

>«В репы такое не возьмут» не из-за Линтиана, а из-за того, что это несовместимо вообще со всем процессом сборки.

задачи бывают разные. мне например совершенно неохота заморачиавться и делать сборку СВОЕЙ программы следуя всем идиотским формальностям вроде патчей, а таким методом можно собирать прямо из мейкфайла

Зачем для сборки своей программы патчи? :) Патчи делают мейнтейнеры, а разработчик программы внесёт изменения прямо в код.

А как правильно сделать встроенную в тарболл сборку пакета - за этим см. arora. Скачайте с http://code.google.com/p/arora/downloads/list тарболл и посмотрите на содержимое файла builddeb.sh. (Никто не говорит, что это должен быть именно sh, можно и в Makefile встроить.)

>ставящие всё в /opt

а что, надо ставить весь сторонний хлам в /usr? там должны жить пакеты из дистрибутива.

Мне больше по душе политика фряхи: все, что не относится к базовой системе, ставится в /usr/local

Аналогия:
Какие там еще «задачи» по приходу домой позволяют кушать с немытыми руками ?

Бардак и дурной тон == мусарня в системе.

>Бардак и дурной тон == мусарня в системе.

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

> всем идиотским формальностям вроде патчей

Бред же , и дикость ...
Гаечный ключ - это тоже формальность ? Зубами гайки откручивать проще, да.

чего-то никто не сказал про ебилды

Извините, что офтопик но я в шоке. http://modeemi.fi/~tuomov/ion/news.html Вот что там пишет создатель iona I have recently given up on the failure known as Linux, and switched to Windows. As I thus probably won't be working much on Ion3 anymore, and since it seems very stable anyway, the 28-day clause in the license should serve little practical purpose anymore. It has therefore been lifted.

Вы все неудачники! epatch решает! ebuild рулит! Хаха!

Что этот фин невменяем и не создатель ion - это давно известно.

Ну тут вопрос, скорее, в простоте deb-ианизации или rpm-изации абстрактного source.tar.gz. Что проще — создать (и понять) иерархию deb или spec для rpm написать?

Спек я писал, помнится. А вот работа по созданию дебиан-пакета из исходников предстоит до конца недели. Вот и посмотрим, где граблей больше. :)

я не знал. И если он не создатель то основной и единственный разработчик.

судя по http://modeemi.fi/~tuomov/ion/download/ion-3-changelog.html

> Что проще — создать (и понять) иерархию deb или spec для rpm написать?

Если чистааа для себя - проще всего сделать dh_make && debuild -b. Или вообще checkinstall.

>самые простые - слакбилды =)

Неужто может быть что-то проще ебилдов? :)

>чего-то никто не сказал про ебилды

Просто митьки никого не хотят победить :)

Скорее уж не для себя, но работа такая. Нужен .deb из локальных исходников и пара новых версий открытых пакетов с новой, нужной нам функциональностью, для которых дебов еще не создали. Как создам — может и отдам мантейнерам, пущай положат в репозиторий. Но за совет — спасибо!

ion ненужен

http://blog.flameeyes.eu/2009/11/05/distributions-are-the-strength-of-linux

или сразу cdbs:
http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml

> А вот работа по созданию дебиан-пакета из исходников предстоит до конца недели. Вот и посмотрим, где граблей больше. :)

Исходники секретные или лежат где-то? Если в открытом доступе, киньте ссылку, посмотрю.

Текст минимального слакбилда, к примеру, в 2 раза меньше того, что ты написал, и в нём будет лишь одна команда/сущность (c 2-мя параметрами), неизвестная для не-слакварщиков - makepkg :) Низачот.

>Неужто может быть что-то проще ебилдов? :)

имеется ввиду - набрать в консоли команду для установки или написать с нуля?

Из открытого нужно пересобрать openct/opensc (http://www.opensc-project.org/openct/). Последних релизов я в дебах не нашел. А надо, туда поддержку нужного нам железа добавили. Там, похоже, все просто: возьму предыдущий deb и сделаю «по образу и подобию» :)

Остальное пока закрыто.

«На третий день Зоркий Глаз заметил, что в комнате нет одной из стен» (C)

Уже по всему миру lzma, а дебианщики до сих пор tar.bz2 осиливают...

> Там, похоже, все просто: возьму предыдущий deb и сделаю «по образу и подобию» :)

А скачать новый тарболл и натравить на него uupdate не айс? :p

Поддержка tar.lzma в формате тоже есть. Только в официальном дистрибутиве её отключили (в Дебиане, есть ли в Убунте - не знаю).

А это что за дебиановский automake? :))

Будем на ночь покурить. Глядишь засну лучше. :)

Сначала, по хорошему, собрать надо оба пакета «с нуля, конфигурой-мэйком в чистый --prefix» и посмотреть что изменилось. Может и айс :)

мимо - это описаны действия или манипуляции по приготовлению deb пакета.

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

cdbs не нужен. Это был костыль для старого debhelper'а. С dh 7, я считаю, всё и понятнее и гибче.

тсссс, это секретная мечта идиота ))

)) как скажешь

Вот мне тоже показалось, что в документации многабукаф. Мир должен быть попроще как-то :))

куда уже проще ?            

debian/rules for a C/C++

#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

---------

Нет, для своего времени CDBS был прорывом, это безусловно. Одно дело вставлять по десять команд dh_* в каждый rules, другое - включить один mk-файл и не париться.

Другой вопрос, что CDBS - это фреймворк, а debhelper как был простым набором утилит, так и остался, даже с dh. Но для того, чтобы понять, как сделать одно и то же, в случае dh нужно читать в разы меньше документации, а интуитивно понять способ действий проще.

И как всякий фреймворк, конечно, CDBS ограничивает свободу действий. Например - и я на эти грабли напоролась с quassel - там никак нельзя сделать две сборки с разными configure-параметрами. Ну то есть вообще никак. А здесь - override_dh_auto_configure, override_dh_auto_build и вперёд паровозом.

Есть всё-таки и сейчас юскейсы, где CDBS удобнее. Та же Жаба с Антом, например. Но их число неуклонно сокращается.

Есть всё-таки и сейчас юскейсы, где CDBS удобнее. Т

И гном на нем топчут, лишь бы тарбол не от больного на голову был.

Цитируем elipse

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

Сказали же «по сравнению».

Я что-то сходу не уверен, что cdbs у меня есть на сборочных серверах. Не все так просто как кажется, иногда приходится ограничивать творческие порывы инфраструктурой :)

Видимо, ограничимся dh_make и dpkg-buildpackage.

> Сказали же «по сравнению».

А где это «сравнение» - это причитания неосиляторов ?
Дык, им не все равно ли что поносить ? ))

> Я что-то сходу не уверен, что cdbs у меня есть на сборочных серверах.

На сборочных серверах лучше всего поставить pbuilder или sbuild, тогда они пусть всё в чруте из дистрибутива тащат, что нужно.

С нуля написать. Команду набрать установки - любой сможет, ума много не надо.

> debian/rules for a C/C++

#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk

include /usr/share/cdbs/1/class/autotools.mk

Только это только для autotools, а тот debian/rules в три строки с первой страницы - ещё и для cmake и много для чего. :)

Кхм ... ну ну

http://cdbs.ueberalles.net/galculator.html

И сравните на досуге с содержимым боевого пакета.

>имеется ввиду - набрать в консоли команду для установки или написать с нуля?

Ну, мы тут именно про создание пакетов говорим. Команду на установку отдать с консоли, вроде, во всех системах ± похоже :)

> Круто! Научиться бы еще самому с легкостью дебы собирать. Если кто занимается сборкой - по каким мануалам учились и какие инструменты облегчающие сборку используете?

Хрена ль толку от пакетов? Всеравно пакет собирается под пределенный дистриб определенной версии. На других дистрибах, или на том же дистрибе другой версии с установкой пакета у пользователя обязательно возникнут нерешаемые проблеммы.

Зачем нужны эти загадочные пакеты, если софт в них невозможно распространять?

> Зачем нужны эти загадочные пакеты, если софт в них невозможно распространять?

Ого !! Отсыпь , не жадничай ...))

намекаешь на венду? тогда бессмысленный вброс
на tar.gz? будет ещё веселее, чем с пакетами, позапрошлый век

а вообще изволь почитать про OpenSUSE Build Service и аналоги (если они конечно есть)

> намекаешь на венду? тогда бессмысленный вброс
на tar.gz? будет ещё веселее, чем с пакетами, позапрошлый век

Намекаю на нормальную систему установки программ. Чтоб пользователь не зависел от майнтейнеров и репозитариев. Именно так дела обстоят в DOS/Win/MacOS/Solaris, только в линухе все через жопу.

а вообще изволь почитать про OpenSUSE Build Service и аналоги (если они конечно есть)

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

Нормальная система - это та, по итогам работы которой десятки программ используют свою копию библиотеки вместо того, чтобы разделять ее (разделяемые библиотеки наверное не случайно появились)? На все это Г никаких ресурсов не хватит, я уже молчу про тормозные «технологии» на управляемых языках, после всего этого не удивительно, почему у перечисленных тобой систем такие требования к железу.


PS: понравился DOS в списке :)

>Причем тут слакбилда ?

Чтобы дать оценку сложности создания deb пакетов, в сравнении

Что, научились уже иметь в системе пару компиляторов разных версий

и без головняков и приседаний ?

Это разве заслуга deb-пакетов как таковых? :) Нет, не научились