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

>Патчи отдельно, исходник отдельно. Что не так?

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

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

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

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

да ни разу. для этих придумано хранить патчи и все такое в git.

Это для тех, кто хочет скачав пакет быстро понять, что там за патчи, сколько их и что изменилось. Прозрачности больше.

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

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

а src.deb это что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rpmfind.net

rpmforge.net

> rpmfind.net

rpmforge.net

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

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

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

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

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

Собственно, в альтовых спеках проблема ровно та же, что и в дебхелпере - слишком много дистроспецифичных (и специфичных для некоторой версии) макросов. Каюсь, сам когда-то приложил к этому руку. А так - почти настоящий RPM-спек. Только пересобрать «одним движением» большинство srpm'ов всё равно не получится - пакеты, прописанные в зависимостях, по-разному называются в разных дистрибутивах.

> rpmfind.net

rpmforge.net

rpm.pbone.net

Кто больше? :)