Debian объявляет об официальной поддержке DebSrc3.0

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

>Все так, кроме того, что патчи и исходники запакованы в один src.rpm.

а src.deb это что?

Я об этом и говорю. В Debian изменения и исходник из апстрима распространяются в двух отдельных файлах orig.tar.gz и diff.gz. Сейчас будут в виде orig.tar.* и debian.tar.*

Их еще синхронизировать надо. Кроме того, их там три части. И какой смысл?

Далеко не у всех, я гарантирую это ) См. выше про полдня. И не то чтобы руки сильно кривые, просто с полного нуля понять, даже с объяснениями и примерами, структуру спека, что там должно быть, и что оно должно делать, и потом заставить его всё собраться без ошибок — задача далеко не на 15 минут. Ну а сделать всё как надо, прочитав хаутушек кб так на 600-800 — тем более.

>в srpm все исходники и патчи уложены в один cpio. А тут (теперь) в один ar. Вся разница.

Не-а, не в один ar, а все как и было — два разных файла + .dsc. Исходники так в репозиториях и хранятся:

http://people.debian.org/~hertzog/packages/debsrc3.0/

>Но если есть гит с ними, то это же имхо все равно в разы более удобный вариант, не?

да не всегда. Вот есть, к примеру, глючный rdesktop в федоре и есть вменяемый в альте. Но пересобрать альтовый пакет в федоре нереально из за невменяемого альт-спека.

Но благодаря мудрому формату спека и устройства РПМ нам ничего не стоит качнуть src.rpm из альта, посмотреть список патчей в нем ибо они не одним файлом лежат, а отдельно, переложить в федорный пакет и пересобрать. Все.

А git надо узнавать, где он там, что там с доступом и т.д. и т.п.

>Далеко не у всех, я гарантирую это ) См. выше про полдня. И не то чтобы руки сильно кривые, просто с полного нуля понять, даже с объяснениями и примерами, структуру спека, что там должно быть, и что оно должно делать, и потом заставить его всё собраться без ошибок — задача далеко не на 15 минут.

По простому берешь аналогичный пакет, меняещь название, версию и уточняешь список файлов. Все.

>Не-а, не в один ar, а все как и было — два разных файла + .dsc. Исходники так в репозиториях и хранятся:

apt-get source качает три файла?

Если исходных кодов несколько, то патчи обычно идут разныы и версии получаемого пакета будут разные, а значит надо делать разные (возможно чуть-чуть отличающиеся) spec файлы (или какой там аналог spec'ав в debian'е ? )

>Их еще синхронизировать надо. Кроме того, их там три части. И какой смысл?

Дык смысл-то — это сугубо внутридебианные улучшения. Так поудобнее синхронизировать работу с другими дистрибутивами. Например, с ubuntu. Качают исходники из одного корыта (unstable). Там, где надо, просто подмахивают файл с патчами на свой ubuntu.debian.tar.*. Все дела. Я же говорю, что изменения эволюционные. Да и просматривать патчи гораздо удобнее (это было одной из целей изменений). Понятно, что и без этого жили, но улучшения же все-таки нужны. Там еще есть кое-какие полезные изменения, но они опять касаются Debian.

> А git надо узнавать, где он там, что там с доступом и т.д. и т.п.

Время на «где гит» врядли будет существенно отличаться от времени на «где пакет». Доступ на чтение вроде бы должен у всех быть. А плюсы, помимо всяких чисто гитовых плюшек, в том, что можно сразу видеть и таскать только нужные патчи, без исходника. После этого, в смысле в случае, если есть гит, дебы/рпмы с сорцами имхо тут юзать вообще незачем. Ну а если его нет, то минус хранения всего в одном .src.rpm получается только в том, что если что, тащить надо не (обычно, по сравнению с остальным) копейки патчей, а всё, то есть просто трафик.

apt-get source качает три файла?

Ага. А потом вызывает dpkg-source, чтобы распаковать orig.tar.gz, приложить diff.gz.

c$ apt-get source bash
Чтение списков пакетов... Готово
Построение дерева зависимостей       
Чтение информации о состоянии... Готово
Нужно загрузить 2471kB архивов с исходными текстами.
Получено:1 http://ftp.fi.debian.org lenny/main bash 3.2-4 (dsc) [1108B]
Получено:2 http://ftp.fi.debian.org lenny/main bash 3.2-4 (tar) [2315kB]
Получено:3 http://ftp.fi.debian.org lenny/main bash 3.2-4 (diff) [155kB]       
Получено 2471kБ за 8s (276kБ/c)    

> По простому берешь аналогичный пакет, меняещь название, версию и уточняешь список файлов. Все.

Не, ну если уж на то пошло, то первый раз я этот пакет ставил вообще из сюсевского srpm тупо через rpm-rebuild кажется, и вообще не заглядывая ни в какие спеки, и ничего не меняя. Работало. Падало, правда, иногда, но в общем работало ) А если уж лезть редактить спеку, то как минимум надо знать, что означает всё то, что ты там видишь, имхо )

Тем более на название и версию в моем случае вообще начхать, кто туда смотреть-то будет. А вот список и пути файлов, разрешения, доп. конфиги, патчи, pre и post-скрипты, вопросы при обнаружении «фашистской политики сборки», или как там её — это всё совсем не 15 минут )

Я думаю, что с разными версиями как было, так и остается. Никто же в здравом уме не будет слепо присобачивать старый /debian (он аналог spec) к новой версии из upstream. Тут речь идет о случае, когда исходные тексты одной версии распространяются апстримом в разных тарболах. Их так и кладут тогда отдельно (это одно из заявленных улучшений, см. sample1 или sample7 на куски с суффиксом component):

http://people.debian.org/~hertzog/packages/debsrc3.0/

Сопровождаемость улучшается тогда. Для них /debian один. и кода распакуется это дело, то будет лежать

\package-<ver>
   \component1
   \component2
   \component3
   \debian

Как-то так должно быть (это в старом proposal для нового формата было, но сейчас как — не знаю)

> Какое всё-таки устаревшее говно dpkg & friends

Зато легко на коленке сделать! создал временный катлог, скопировал в него будущий usr/, создал каталог DEBIAN/, в который положил control с зависимостями и описанием, потом dpkg-deb - и вуаля, пакет готов. Удобно, когда хочется хакнуть зависимости под себя. Для рпмки же еще отдельный список файлов составлять надо

srpm конечно по-мощнее, эта штука позволяет пэкэджеру учесть, на каком дистрибутиве собирается пакет, если это имеет значение

>Ну а если его нет, то минус хранения всего в одном .src.rpm получается только в том, что если что, тащить надо не (обычно, по сравнению с остальным) копейки патчей, а всё, то есть просто трафик.

Ну это немаловажно для реализации patch tracking system, которая будет автоматически извлекать патчи из небольшого файла (а не целиком пакет) с целью их обработки. Сейчас патчи, к тому же, будут иметь заголовок, где будут указаны автор, даты, что патч делает и т .д.

Что-то типа такого: http://patch-tracker.debian.org/

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

> а то есть есть серваки, которые до сих пор на 3ем или 4ом деби крутятся.

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

>> Пакет deb - переименованный архив, в котором содержаться ещё два архива, в которых лежат ещё по несжатому архиву. Всё это работает с утилитами, пришедшими из UNIX в 80-х годах.

Да,и к тому же не подписанный. :(

Есть и файл с подписью.

>srpm конечно по-мощнее, эта штука позволяет пэкэджеру учесть, на каком дистрибутиве собирается пакет, если это имеет значение

Это потому что в rpm это имеет значение :}

> Ну это немаловажно для реализации patch tracking system, которая будет автоматически [..]

Так а не легче тогда уже сделать такую систему на чем-то типа гита или типа того? В общем, а тем более в перспективе, намного прямее и функциональнее же, не? Идеально туда же еще функцию автосборки, для получения конечного продукта, что-то типа билдсервиса, под некоторый набор дистр/архитектура/версия дистра.

>Так а не легче тогда уже сделать такую систему на чем-то типа гита или типа того? В общем, а тем более в перспективе, намного прямее и функциональнее же, не?

Ну дык эта тема уже прорабатывалась! В Debian даже понаделали репозиториев для сопровождающих на разных VCS, потому что, наверное, каждый хочет делать по-своему. Вот статистика по их использованию (svn с большим отрывом лидирует, потом идет git):

http://upsilon.cc/~zack/stuff/vcs-usage/

В этих репозиториях (например, http://git.debian.org) можно получить историю изменений /debian и патчи, которые прилагались. Не знаю, что с этим дальше собираются делать. То есть либо выбор еще не сделан, но он планируется на отдаленное будущее, либо по каким-то техническим причинам выбрали вариант DebSrc3.0 как некоторый общий формат. На ЛОР есть Debian Developers и те, кто читают devel рассылку. Они, может быть, скажут, что и почему.

Братцы, вон ALT уже в git всё хранит, а вы только до уровня src.rpm десятилетней давности добрались ;)

> В этих репозиториях (например, http://git.debian.org) можно получить историю изменений /debian и патчи, которые прилагались. Не знаю, что с этим дальше собираются делать. То есть либо выбор еще не сделан, но он планируется на отдаленное будущее, либо по каким-то техническим причинам выбрали вариант DebSrc3.0 как некоторый общий формат

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

>Время на «где гит» врядли будет существенно отличаться от времени на «где пакет».

rpmfind.net

rpmforge.net

>Не, ну если уж на то пошло, то первый раз я этот пакет ставил вообще из сюсевского srpm тупо через rpm-rebuild кажется, и вообще не заглядывая ни в какие спеки, и ничего не меняя.

нет. ну это означает, что у тебя уже есть src.rpm. Тогда, понятно,

rpm --rebuild xxx.src.rpm и готово.

Я имел в виду ситуацию, когда спека нет. Есть только тарбол с сайта программы и в нем спек не лежит.

А если уж лезть редактить спеку, то как минимум надо знать, что означает всё то, что ты там видишь, имхо )

Ну в нем все очевидно.

Name: наверное, тут имя

Version: а тут вероятно версия.

%files

неужто список файлов?

Тем более на название и версию в моем случае вообще начхать, кто туда смотреть-то будет.

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

А вот список и пути файлов, разрешения, доп. конфиги, патчи, pre и post-скрипты, вопросы при обнаружении «фашистской политики сборки», или как там её — это всё совсем не 15 минут

Ну, вопросы при обнаружении «фашистской политики сборки», это травмы альта, остальное как раз 15 минут.

Получено:1 http://ftp.fi.debian.org lenny/main bash 3.2-4 (dsc) [1108B]

Получено:2 http://ftp.fi.debian.org lenny/main bash 3.2-4 (tar) [2315kB]

Получено:3 http://ftp.fi.debian.org lenny/main bash 3.2-4 (diff) [155kB]

ну, кошмар.

надеюсь там велосипедов не наделают, чтобы можно было бы брать исходники и собирать их на других дистрибутивах тоже, где нет дебиан-специфичных утилит

А разве это плохо , если можно будет брать исходники и собирать их на других дистрибутивах тоже ?

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

Так ?

> rpmfind.net

rpmforge.net

(пожимая плечами) google://altlinux git. И? )

> нет. ну это означает, что у тебя уже есть src.rpm. Тогда, понятно, rpm --rebuild xxx.src.rpm и готово.

Эм, я на федору так лепил пакет от сюси, причем более древней. Это уже рекомендованный и вообще нормальный метод? ;)

Ну в нем все очевидно.

Там обычно бывает намного больше слов, чем только name, version и %files ) Которые имеют немного большую важность для нормальной установки и работы софтины, чем имя и версия. И с нуля понять и проверить корректность их всех дело небыстрое. А если не проверять, то да, rpm --rebuild чей_угодно_первый_попавшийся_src.rpm и всё, зачем те спеки )

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

Ну и я про то же. Да даже от этой же, только для другого дистра, при нулевых знаниях о сборке софта в линуксе вообще (ну за исключением варианта ./configure && make && make install ;)

Ну, вопросы при обнаружении «фашистской политики сборки», это травмы альта

Это были мои травмы, когда я не перечислил все собранные файлы в спеке ) И конкретно альт туда никакого отношения не имел, только федора, центось (для неё тоже нашел сорцрпм для этой софтины), и сюся (третий найденный пример). И даже с такими подпорками + полные хаутушки — пока об всё поспотыкался, время и ушло )

>Эм, я на федору так лепил пакет от сюси, причем более древней. Это уже рекомендованный и вообще нормальный метод? ;)

А что такого? Проблемы переносимости спеков между дистрами только в специфичных макросах и названиях пакетов в зависимостях. Недавно еще переход на lzma случился, так что иногда приходится вручную распаковывать исходники и спек для понимания более старым rpm.

Там обычно бывает намного больше слов, чем только name, version и %files ) Которые имеют немного большую важность для нормальной установки и работы софтины, чем имя и версия.

90% программ собираются configure make и make install

Вот это и забито в спеке между названием и %files

И с нуля понять и проверить корректность их всех дело небыстрое. А если не проверять, то да, rpm --rebuild чей_угодно_первый_попавшийся_src.rpm и всё, зачем те спеки )

Ну если собралось - хорошо. Если нет, поправил названия и опять хорошо. ;)

Это были мои травмы, когда я не перечислил все собранные файлы в спеке )

это бывает. но дерево установки же сохраняется. вывод find или tree посмотрел и внес исправления. и все...

>(пожимая плечами) google://altlinux git. И? )

А зачем гугл тогда? Ищи сразу тольк в альтлинуксе.

rpmfind.net ищет сразу в десятках дистрибутивов.

> А что такого? Проблемы переносимости спеков между дистрами только в специфичных макросах и названиях пакетов в зависимостях

Как минимум еще пути в %install/%files и скрипты в pre(un) и post(un). Это только то, что мне попалось, полные доки по сборке не изучал.

90% программ собираются configure make и make install

Была бы задача тупо получить рабочий бинарник, зачем эти пакеты вообще нужны были? ) Скачал .tar.bz2, одну команду отдал и вуаля.

Ну если собралось - хорошо. Если нет, поправил названия и опять хорошо. ;)

Со временем начинает хотеться большего. Не просто собранного пакета, а еще и собранного более-менее как надо ) В конце-концов, а что делать, если покрасноглазить хочется, но гента выглядит немного overkill'ом )

это бывает. но дерево установки же сохраняется. вывод find или tree посмотрел и внес исправления. и все...

Так я ж не против. Инфа есть, гугель есть, хаутушки есть, и всё такое. Просто каждая такая вещь отнимает по достаточному куску времени, чтобы в сумме ушел не один час (ну не непрерывно, конечно).

А зачем гугл тогда? Ищи сразу тольк в альтлинуксе.

rpmfind.net ищет сразу в десятках дистрибутивов.

Разговор был не о том, а о сравнительном времени на поиск нужного .src.rpm и нужного гита с исходниками и патчами.

Теперь понятно, почему для особо желающих src.rpm выкладываются (могут быть не тривиальные %postin, например, с созданием групп пользователей), а вот «архив» со всем необходимым для сборки deb - нет.

>Как минимум еще пути в %install/%files и скрипты в pre(un) и post(un). Это только то, что мне попалось, полные доки по сборке не изучал.

пути везде одинаковые. %_prefix %_bindir etc

Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

Была бы задача тупо получить рабочий бинарник, зачем эти пакеты вообще нужны были? ) Скачал .tar.bz2, одну команду отдал и вуаля.

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

Со временем начинает хотеться большего. Не просто собранного пакета, а еще и собранного более-менее как надо ) В конце-концов, а что делать, если покрасноглазить хочется, но гента выглядит немного overkill'ом )

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

Так я ж не против. Инфа есть, гугель есть, хаутушки есть, и всё такое. Просто каждая такая вещь отнимает по достаточному куску времени, чтобы в сумме ушел не один час (ну не непрерывно, конечно).

оно оправдывается. собраный пакет потом ставится в разные системы, а опыт сборки обогащает общее понимание системы.

Разговор был не о том, а о сравнительном времени на поиск нужного .src.rpm и нужного гита с исходниками и патчами.

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

Со временем начинает хотеться большего

Тогда стоит вложить немного времени в изучение "Maximum RPM"

Недавно я разговорился с преподавателем информатики 51 года от роду. Он азартно хвалил инициативу "линукс в школах". Я спросил - почему? Ответ был колоссально прост.

Он сообщил, что в силу возраста ему лично трудно за всем поспевать. Технологий много новых, дети кучу всего знают, спрашивают. А тут - панацея! Объем преподавания резко сокращается (ведь достаточно только узреть линукс и всё, другое ничего не нужно), уходят узкопрофильные задачи (зачем объяснять, что такое базы данных, если понятно, что любая опенсорсная БД априори лучше любой другой?), плюс - внимание! - можно просто чуть изменив, перечитывать материал 20ти летней давности.

Давясь от счастливого смеха, он стоял передо мной и говорил - "Я в перестройку читал про команды MS-DOS, потом это всё пошло развиваться, столько всего нового, а теперь мне повезло - опять можно команды начитывать, практически те же самые, и если мне скажут, что я читаю старьё, которое никому не нужно - я отвечу - теперь это сверху признано самыми передовыми технологиями!"

Вот она, целевая аудитория линукса в школах, которая с удовольствием поддержит его внедрение - учителя, которые не тянут современные технологии.

Главное, в каждом курсе по линуксу - более 50% времени на идеологические мантры. "Вот мы вводим команду ls, она выводит содержимое каталога - да, как великолепно, в других ОС этого нет, это - тот самый хай-тех, про который везде говорят, как нам повезло, что у нас линукс". Дети кивают - да, как нам повезло.

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

Результат - все довольны. Линукс, который не могут продать на коммерческом рынке, был продан через откатные схемы в школы (через по-быстрому для этого 1го контракта сделанную фирму, что и не скрывается). Региональные школы получат доп. деньги - налом, с родителей. Родители поймут, что в минобразования - конченые мудаки (тут Фурсенко не подкачает, думается).

Истину глаголишь! Как со Слаки слез пакетики ежели только checkinstall'ом собираю.

А вобще, использование АПТ в рпмных дистрибутивах как бы намекает...

> надеюсь там велосипедов не наделают, чтобы можно было бы брать исходники и собирать их на других дистрибутивах тоже, где нет дебиан-специфичных утилит

1. orig.tar.gz, неоднократно упомянутый в ходе темы, ни на что случайно не намекает?

2. Зачем брать исходники из пакетов дебьяна?

> Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

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

> пути везде одинаковые. %_prefix %_bindir etc

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

Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

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

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

Так я про это же — чтобы получить не только что-то собранное и кое-как взлетающее, а то, что надо, `rpmbuild --rebuld` вполне может оказаться недостаточно.

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

Не то чтобы прям очень нравится, был бы выбор — врядли бы этим занимался, по крайней мере сейчас. Но софтину хочется, в репах нет, сходу ставить сильно отличающийся .srpm не совсем Ъ, так что и выбора нет )

оно оправдывается. собраный пакет потом ставится в разные системы, а опыт сборки обогащает общее понимание системы.

Не спорю, но это плюсы или для покрасноглазить, или кому по долгу службы положено. В перспективе имхо хотелось бы развития функциональности билдсервисов для более «обычных» юзеров, типа скармливаешь ему архив с исходниками и через минуту получаешь пакет, собранный прямо под тебя. Только ради таких мелочей арч/гента/etc всё же перебор.

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

Там было всё же другое, насчет зачем пилить функциональность пакетов с сорцами, как в сабже, чтобы удобнее было таскать оттуда патчи и т.д., если вроде бы кошернее будет делать это в системе типа git.

Эту*

Кстати, вопрос знатокам srpm - из него можно генерить более одного пакета?

Толсто.

Мне лет 8 назад начитывали материал по ДОСу, ничего, живой. Забавно было наблюдать однокласников неосиливающих нортонкоммандира) Вот начавшаяся потом дрессировка мышкотыкания это да, крепкий маразм был...

> Тогда стоит вложить немного времени в изучение «Maximum RPM»

Это находил. Но, как правильно написано в названии, тут уже скорее не больше а максимум )

Кстати, вопрос знатокам srpm - из него можно генерить более одного пакета?

Да. Подробности — в «Maximum RPM», ссылка выше по топику

> «Вот мы вводим команду ls, она выводит содержимое каталога - да, как великолепно, в других ОС этого нет, это - тот самый хай-тех, про который везде говорят, как нам повезло, что у нас линукс»

Не понел, в семерке dir выкинули, что ли? ;)

нам это навязали сверху

а что мы можем сделать

вашим детям потом в институт, работать, им это не нужно

деньги, которые вы доплачиваете, это вложение в будущее

вы же не хотите, чтобы они тому же обучались, чему и вы 20 лет назад?

Родители поймут, что в минобразования - конченые мудаки

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

> Кстати, вопрос знатокам srpm - из него можно генерить более одного пакета?

Да. Обычно более одного и получается.

Ок, спасибо.

И тебе.