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

Вообще-то, отдельные патчи и сейчас есть. Они и давно были. Поддерживаются через quilt/dpatch. Патчи можно обнаружить в /debian/patches (если, разумеется, сопровождающий именно таким образом патчит исходники). Если бы апстрим захотел бы глянуть патчи, то он должен был скачать исходники (orig.tar.gz, diff.gz и .dsc), распаковать их через dpkg-source и залезть в /debian/patches.

Вот, к примеру, /debian/patches из icewm

00list                    i18n_updates.dpatch        package_build_fixes.dpatch
compiler_defaults.dpatch  iconify_on_wm_hint.dpatch  tray_hotfixes.dpatch
cvs_fixes.dpatch          misc_fixes.dpatch
debian_defaults.dpatch    move-to-screen.dpatch

Насколько я понимаю, просто поменяли способ хранения. Т. е. достаточно будет распаковать debian.tar.*, чтобы получить каталог /debian с патчами. И теперь каталог /debian не будет находиться внутри исходного кода, а будет уровнем выше, а исходных кодов (разных версий upstream) может быть уже несколько, т.е . несколько orig.tar.gz.

В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

>а исходных кодов (разных версий upstream) может быть уже несколько, т.е . несколько orig.tar.gz.

Только не разных версий, а просто если апстрим исходники одной версии в нескольких тарболах отдает (такое встречается).

В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

$ rpmdev-extract polipo-1.0.4-1.src.rpm

warning: polipo-1.0.4-1.src.rpm: Header V3 DSA signature: NOKEY, key ID 91df7ddd
polipo-1.0.4-1.src/polipo-1.0.4.tar.gz
polipo-1.0.4-1.src/polipo-allowHttpUnknown.patch
polipo-1.0.4-1.src/polipo-makefile.patch
polipo-1.0.4-1.src/polipo.config
polipo-1.0.4-1.src/polipo.forbidden
polipo-1.0.4-1.src/polipo.init
polipo-1.0.4-1.src/polipo.spec

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

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

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

>В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

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

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

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

Ах да, еще догадались иерархию debian/* вынести из тарбола с исходниками. А то непонятно, если тарболов несколько, в каком из них искать всю эту управляющую тряхомудию по сборке пакета

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

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

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

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

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

а src.deb это что?

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

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

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

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

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

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

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

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

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

>Не-а, не в один 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)    

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

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

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

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

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

>Ну а если его нет, то минус хранения всего в одном .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

Получено: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. И? )

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

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

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

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

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

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

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

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

> (или какой там аналог spec'ав в debian'е ? )

debian/rules. А откуда, Вы думаете, у дебианщиков эта святая уверенность, что в Дебиане всё всегда сделано идеально для некоторого момента времени? Их же каждой мелочью воспитывают, как победителей (далее нецензурно).

> rpmfind.net

rpmforge.net

rpm.pbone.net

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

> ну, кошмар.

Пожимая плечами - ну, в общем, ничем не хуже rpm -i somepackage.src.rpm :) Даже лучше - всё в текущем каталоге, бери и собирайся :)

> Пожимая плечами - ну, в общем, ничем не хуже rpm -i somepackage.src.rpm :) Даже лучше - всё в текущем каталоге, бери и собирайся :)

давно не смотрел как в федоре, а в мандриве эта команда распаковывает .src.rpm в ~/rpmbuild, а это даже лучше чем текущий каталог.

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

Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

[code]Patch0: polipo-makefile.patch Patch1: polipo-allowHttpUnknown.patch [..] %prep %setup -n polipo-%{version} %patch0 -p1 -b .makefile %patch1 -p1 -b .allowHttpUnknown[/code]

За корректность не ручаюсь, но это там таки есть.

Сорри, форматирование

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

Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

Patch0: polipo-makefile.patch
Patch1: polipo-allowHttpUnknown.patch
[..]
%prep %setup -n polipo-%{version}
%patch0 -p1 -b .makefile
%patch1 -p1 -b .allowHttpUnknown

За корректность не ручаюсь, но это там таки есть.

>Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

Вопрос: а в SRPM патчи — это единственно установленный способ внесения изменений в исходники или нет? Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

> Вопрос: а в SRPM патчи — это единственно установленный способ внесения изменений в исходники или нет? Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Если что, я тот анонимус, который полдня один пакет собирал, и пока всё, так что много не подскажу ) Но в смысле, зачем сгенерируется патч? Поправите исходники, положите их такими в srpm и всё. Проблемы, как я понимаю, будут только у тех, кому захочется взглянуть на модификации исходника — им надо будет самим искать и diff'ать оригинал, вместо того чтобы просто взять отдельные патчи из srpm.

>Пожимая плечами - ну, в общем, ничем не хуже rpm -i somepackage.src.rpm :) Даже лучше - всё в текущем каталоге, бери и собирайся :)

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

Нет, ну зачем патч сгенерируется, я понимаю. Перефразирую вопрос: хранение оригинальных исходников из upstream внутри SRPM обязательно или нет? То есть могу ли я не использовать внутри SRPM схему orig+diff (или orig+set_of_patches), а сразу положить туда уже *исправленные* исходники без orig? Я к тому, что в Debian схема orig+diff установлена, как единственная. Сейчас только речь идет о том, в каком виде этот diff поставлять.

Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Вопрос не совсем понятен. Сам по себе RPM никаких diff'ов не делает, ни больших, ни маленьких. Сделать с upstream'ными (aka ванильными) исходниками перед упаковкой их в .src.rpm (посредством прописывания в Source0, Source1 и т. д.) можно все, что угодно, в принципе. Другое дело, что, к примеру, Fedora Packaging Guidelines модификацию ванильных исходников крайне не рекомендуют. Можно пример — что есть и чего хочется?

> Нет, ну зачем патч сгенерируется, я понимаю.

Это просто я не понял )

То есть могу ли я не использовать внутри SRPM схему orig+diff (или orig+set_of_patches), а сразу положить туда уже *исправленные* исходники без orig? Я к тому, что в Debian схема orig+diff установлена, как единственная. Сейчас только речь идет о том, в каком виде этот diff поставлять.

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

Нет, ну зачем патч сгенерируется, я понимаю. Перефразирую вопрос: хранение оригинальных исходников из upstream внутри SRPM обязательно или нет?

собственно, как и в дебиане, это не технический вопрос, а вопрос политики сборки пакетов.

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

ты сознательно или нет путаешь пакет с исходниками с пакетом с бинарниками.

а насчет RPM: RPM'у до deb еще много лет развиваться:

* debconf

* зависимости

> * debconf

интерактивные post-install скрипты не нужны

* зависимости

это вопрос не к RPM

debconf

Что это такое?

зависимости

У RPM нету зависимостей? 8-0

> интерактивные post-install скрипты не нужны

поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

это вопрос не к RPM

именно к нему

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

Понятное дело, что всегда можно обмануть Debian, подсунув ему подправленный исходник, а потом сгенерировав еще какой-то diff после, но это обман себя самого. :)

Исходники из upstream в Debian сначала пакуются в orig.tar.gz. А на распакованных исходниках уже осуществляется правка различными способами: либо сразу в коде, либо через систему патчей. А потом из этих изменений при сборке dpkg-source генерирует diff.gz, который вычисляется относительно orig.tar.gz (лежит рядом в директории). Таким образом образуется связка orig+diff, которая и льется в репозиторий исходников.

Сейчас же вместо большого diff будет как бы отдельно хранение Debian-спека (/debian) и патчей с описаниями в одном тарболе (но не в одном diff!)

поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

Чушь и 4.2. К примеру,

$ rpm -q --scripts openssh-server
preinstall scriptlet (using /bin/sh):
/usr/sbin/useradd -c "Privilege-separated SSH" -u 74 \
	-s /sbin/nologin -r -d /var/empty/sshd sshd 2> /dev/null || :
postinstall scriptlet (using /bin/sh):
/sbin/chkconfig --add sshd
preuninstall scriptlet (using /bin/sh):
if [ "$1" = 0 ]
then
	/sbin/service sshd stop > /dev/null 2>&1 || :
	/sbin/chkconfig --del sshd
fi
postuninstall scriptlet (using /bin/sh):
/sbin/service sshd condrestart > /dev/null 2>&1 || :

> А это всё конечно есть, в спеке

Да, разумеется есть :) но, согласитесь, не так наглядно :)

> поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

Конкретика где? Ключи генерируются при первом старте сервиса.

именно к нему

?

> Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Строго говоря, если Вы просто поправите в апстримных исходниках какой-то код, а потом просто завернёте полученное в качестве .tar.gz, rpm не будет Вам мешать. Но так делать /не принято/, это, натурально, моветон.

Вариант с одним большим diff между «настоящим» апстримом и тем, что получилось у Вас в результате правок, нынче является заметно более распространённым явлением, особенно, если разработка пакета ведётся в рамках какой-нибудь системы контроля версий. В этом случае, грубо говоря, историю отдельных изменений предлагается прослеживать по VCS, а не по набору патчей и ченджлогу.

> Чушь и 4.2. К примеру

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

далее существует ряд программ на которые обязательно надо спрашивать у пользователя разрешения. например интеловое firmware. оно распространяться может свободно но пользователь обязан согласиться или нет с лицсоглашением

далее существует масса вещей которые после установки должны «что-то скачать» из инета. делать это без разрешения пользователя не есть очень хорошее решение

Генерация host-ключей при первом запуске предусмотрена в init-скрипте

костыль которым попытались решить проблемы пакетного менеджера

> поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

Толстота. Все это можно сделать неинтерактивно.

> * debconf

Ну, готов отчасти согласиться. Хотя это приводит к феерическим багам, описанным выше.

* зависимости

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

> Понятное дело, что всегда можно обмануть Debian, подсунув ему подправленный исходник, а потом сгенерировав еще какой-то diff после, но это обман себя самого. :)

А потом из этих изменений при сборке dpkg-source генерирует diff.gz, который вычисляется относительно orig.tar.gz (лежит рядом в директории)

А зачем вообще еще дифф и все эти этапы? Может я ваниль и собираю, а что.

> Толстота. Все это можно сделать неинтерактивно

Не всё. Но вопрос в том, нужно ли делать это средствами пакетного менеджера.

> Толстота. Все это можно сделать неинтерактивно.

была программа версии 1, был у нее конфиг в версии между 2 и 3 перешли на конфиг в виде .lua. конвертер обещают примерно к версии 5 (если не забьют совсем)

человек делает обновление дистрибутива. как ему средствами rpm хотя бы сообщить о том что «Вася, тебя ждут такие-то проблемы, ты согласен?»

> а насчет RPM: RPM'у до deb еще много лет развиваться:

Доо.

* debconf

Единственное преимущество, но и его трудно отнести к преимуществам _пакетного менеджера_. Если кто не знает, debconf спроектирован как package manager-agnostic.

* зависимости

Ну-ну, и каких зависимостей нет в RPM? Если что, то «мягкие» зависимости в RPM есть уже несколько лет.

А вот скажи, можно подписать .deb (не надо про Secure APT, это не то)? SHA1 всё так же через стороннюю приблуду? Как насчет транзакций при утановке пакетов?

Блин, даже опции --noscripts в dpkg нет. Ископаемое такое ископаемое.

> Да, разумеется есть :) но, согласитесь, не так наглядно :)

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

> Не всё. Но вопрос в том, нужно ли делать это средствами пакетного менеджера.

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

По большому счёту, ни для чего больше, кроме тривиальных и _очевидных_ действий и нотификаций debconf использовать /потенциально опасно/. Хотя бы по причине возможности unattended install.

> Единственное преимущество, но и его трудно отнести к преимуществам _пакетного менеджера_.

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

то что это реализовано в виде отдельной сущности - простой юниксвей.

А вот скажи, можно подписать .deb

да при сборке подписывается .changes где sha1, md5, sha256 и подпись майнтенера (ну или того кто подписал)

> Как насчет транзакций при утановке пакетов?

Лучше, чем в RPM.

> в неинтерактивном скрипте невозможно учесть все случаи. и получаются идиотизмы вроде того что имеем две fido-шные программы, одна создает группу ftn, а другая группу fido.

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

далее существует ряд программ на которые обязательно надо спрашивать у пользователя разрешения. например интеловое firmware. оно распространяться может свободно но пользователь обязан согласиться или нет с лицсоглашением

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

далее существует масса вещей которые после установки должны «что-то скачать» из инета. делать это без разрешения пользователя не есть очень хорошее решение

А это вообще что, чтобы именно «должны»?

>По большому счёту, ни для чего больше, кроме тривиальных и _очевидных_ действий и нотификаций debconf использовать /потенциально опасно/. Хотя бы по причине возможности unattended install.

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

> Хотя бы по причине возможности unattended install.

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

>> А вот скажи, можно подписать .deb

да при сборке подписывается .changes

Я спросил про подпись .deb. Не Contents-*, не .changes, а .deb

> Не всё.

юзеров добавляй/кеши генерируй/ключи

Из перечисленного? Так то понятно что не всё, что вообще может понадобиться.

Но вопрос в том, нужно ли делать это средствами пакетного менеджера.

Там был вопрос в том, чтобы не делать это самому вручную, а какие тут еще варианты. Разве что тащить с собой скрипт конфигурации, ложить куда-нибудь, и потом как-то извещать юзера, что чтобы работало — надо запустить вот это. Вариант тоже не очень.

>> Как насчет транзакций при утановке пакетов?

Лучше, чем в RPM.

Да неужели? И как же откатить инсталляцию группы пакетов?

> По большому счёту, ни для чего больше, кроме тривиальных и _очевидных_ действий и нотификаций debconf использовать /потенциально опасно/. Хотя бы по причине возможности unattended install.

опять же: вот скажем есть программа версии 1 у нее есть конфиг в версии 2 формат конфига сменился

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

* майнтенер может не учесть все случаи жизни

* пользователь может дорожить своими коментариями итп

* конвертирование может не дать 100% рабчий результат

как без интерактива предлагается разрулить данную ситуацию?

Знаете, к чему это приводит в случае действительно больших транзакций? :)

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

>А зачем вообще еще дифф и все эти этапы? Может я ваниль и собираю, а что.

Ну дык если ваниль в deb собирается, то как минимум понадобится в эту ваниль добавить каталог /debian со всеми правилами сборки. И это система сборки Debian посчитает за изменение исходников. В итоге diff будет состоять из содержимого /debian. Все, что добавлено сопровождающим в родные исходники — все есть diff.

> Да неужели? И как же откатить инсталляцию группы пакетов?

Ответ: как правило, никак :) Но, в отличие от rpm, мы, по крайней мере, получаем консистентную систему, если в середине configure что-нибудь сломалось.

> где проблем не бывает

Бывает. Конкретно в debian'е бывает.

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

См. выше историю про reconfigure на X.

> человек делает обновление дистрибутива. как ему средствами rpm хотя бы сообщить о том что «Вася, тебя ждут такие-то проблемы, ты согласен?»

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

/etc/config.rpmsave

человек делает обновление дистрибутива. как ему средствами rpm хотя бы сообщить о том что «Вася, тебя ждут такие-то проблемы, ты согласен?»

google «%config(noreplace)»

> как без интерактива предлагается разрулить данную ситуацию?

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

> Ну дык если ваниль в deb собирается, то как минимум понадобится в эту ваниль добавить каталог /debian со всеми правилами сборки. И это система сборки Debian посчитает за изменение исходников. В итоге diff будет состоять из содержимого /debian. Все, что добавлено сопровождающим в родные исходники — все есть diff.

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

Ответ: как правило, никак :)

Но иногда можно, по крайней мере инструмент есть

yum --help | grep downgrade
downgrade      downgrade a package

> downgrade downgrade a package

Сдаунгрейдить пакет - это не то же самое, что *откатить* *транзакцию*, вы не находите? А так вообще, у самого обычного rpm есть ключик --oldpackage для установки/апгрейда.

>Тогда мы говорили немного о разном, я думал что диффы в смысле именно патчи исходников ) А так там помимо правил сборки еще много чего может валяться, стартовые конфиги, например. Но они обычно лежат так же отдельно, рядом с патчами и архивом с исходниками, и само собой что упомянуты в спеке, так что если есть желание, то взять нужное вполне просто.

Это и есть объект последних изменений. Теперь изменения действительно могут лежать отдельным патчем или серией патчей в /debian/patches, а содержимое директории /debian (вместе с /debian/patches)не будет превращаться в diff, как раньше, а просто запаковываться и идти в связке с orig. Плюсы еще тут такие, что раньше, например, чтобы заменить картинку в orig, надо было ей uuencode сделать, так как она должна в текстовый diff попасть. Теперь же не надо. Меня не покидает вопрос, почему так нельзя было сделать с самого начала в Debian. Подход, вроде бы, очевидный. Или я что-то в этой жизни не понимаю.

>И как же откатить инсталляцию группы пакетов?

Не транзакционно, но попробовать можно. См. cupt snapshots.

> Сдаунгрейдить пакет - это не то же самое, что *откатить* *транзакцию*, вы не находите? А так вообще, у самого обычного rpm есть ключик --oldpackage для установки/апгрейда.

А о каком именно «правильном» откате тогда шла речь? Таком, который был бы возможен, если бы старые файлы при обновлении не затирались, а переименовывались, для такой возможности, плюс сохранение лога выполненных изменений?

> См. cupt snapshots.

Ух, блин, прикольно. Напрягает только дата публикации:

http://jackyf.livejournal.com/105946.html?thread=215514

безумству храбрых и всё такое. Но интересно, да.

> А о каком именно «правильном» откате тогда шла речь?

О восстановлении системы в состояние, предшествующее апгрейду. Да-да, и чтобы, например, базы данных (в широком смысле, от /etc/passwd до /var/lib/mysql/...), с которыми работают апгрейдящиеся приложения возвращались к тому виду, в котором они были /примерно до апгрейда/.

Иначе это не транзакция, а чёрти что. Да, я в курсе, что в такой постановке решение принимает монстроидальный вид. Но желание клиента (или product manager'а) - закон.

> О восстановлении системы в состояние, предшествующее апгрейду. Да-да, и чтобы, например, базы данных (в широком смысле, от /etc/passwd до /var/lib/mysql/...), с которыми работают апгрейдящиеся приложения возвращались к тому виду, в котором они были /примерно до апгрейда/.

Да, я в курсе, что в такой постановке решение принимает монстроидальный вид.

Что-то даже фантазии не хватает на такой способ, если при установке применяются и pre/post скрипты, а обеспечивать откат должна сама система, своими методами, и без использования инфы из пакета (потому как её там вполне может и не быть).

Ну, отчего ж, «нафантазировать» решение у нас получилось, например, кучка UnionFS'ов, с периодической фиксацией состояния «вниз». Другое дело, что аккуратная реализация довольно громоздка. Ну и ещё там всякие варианты предлагались, промежуточного характера. В общем, задача, в целом, решаемая, но ох непросто...

> поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

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

полностью честные транзакции сделать можно как over deb так и over rpm.

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

> Бывает. Конкретно в debian'е бывает.

обновление на автомате - зло. сисадминов увольнять, которые это делают

> См. выше историю про reconfigure на X.

отматывать лень. X- явнодесктопная шняга. явно обновлялась в примере не из секюрити

> Ну, отчего ж, «нафантазировать» решение у нас получилось, например, кучка UnionFS'ов, с периодической фиксацией состояния «вниз»

И это может нормально прикручиваться отдельно к уже установленной, или хотя бы существующей (какой-нибудь дистр, пусть и не любой) системе?

> А вот убедиться, что юзер это увидел, уже хз как — или автоинсталл, или установка из gui,

в случае с deb мы в этом убеждены. если юзер поставил флаг «отвечать на все 'да'» то фактически он и на наш вопрос _ответ выдал_

и облом. Но это разве задачи формата пакетов?

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

на автомате оно или нет от этого легче не становится, особенно когда security фикс приводит к временной неработоспособности какого-либо сервиса

> /etc/config.rpmsave

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

> важно чтобы была четкая инфа «этот файл от этого пакета»

ну вот и напишите робота, который пройдётся у Вас по $HOME и идентифицирует, какой файл там чему принадлежит ;)

> И это может нормально прикручиваться отдельно к уже установленной, или хотя бы существующей (какой-нибудь дистр, пусть и не любой) системе?

Ну, в рамках нашей задачи, как Вы понимаете, цели осчастливить всех и не предполагалось. Разумеется, в этом случае перед и после апгрейда надо проделать большое число весьма нетривиальных действий, и большинству метапакетных менеджеров «втолковать» это не удастся. Но специально выбранным и модифицированным MPM - отчего нет. В общем, повторюсь, в рамках выбранной области (инсталляция одного или нескольких заранее известных продуктов, пусть даже и с мощной системой зависимостей на OS-vendor'овские пакеты) - задача решаемая. Но, видимо, на практике ещё не решённая в сколько-нибудь интересном объёме. Хотя я уже год как занят другими делами, может, и доковырялись до чего...

> явно обновлялась в примере не из секюрити

Мне, знаете, поровну, отчего мэнтейнер решил положить в апдейты некоторый пакет. Он лучше знает, моё дело [dist-]upgrade'иться.

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

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

> в случае с deb мы в этом убеждены. если юзер поставил флаг «отвечать на все 'да'» то фактически он и на наш вопрос _ответ выдал_

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

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

Флаг «отвечать на всё да» это возможность именно формата пакетов, или тулзы, их ставящей? ;)

> в рамках выбранной области (инсталляция одного или нескольких заранее известных продуктов, пусть даже и с мощной системой зависимостей на OS-vendor'овские пакеты)

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

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

человек обновился до testing, увидел проблемы смотрит в unstable следующая версия в ченджлоге написано что-то похожее на его проблемы. раз и еще разок обновился до unstable.

в случае debian (который на deb-пакетах) он получит вопрос «а не сконвертить ли вам конфиг?»" в случае rpm он получит Х

>>> А вот скажи, можно подписать .deb

>> да при сборке подписывается .changes

> Я спросил про подпись .deb. Не Contents-*, не .changes, а .deb

А смысл?

Тут совершенно другая ситуация описана. Проблемы были сразу после обновления до testing. Если у человека не сохранен конфиг, то он может на выходе получить непойми что и ответ на вопрос «а не сконвертить ли вам конфиг?» его никак не спасет.

> Не понел. Так у меня и в yum такой флаг есть, и? Речь была всего лишь об этом, а не о важности донесения инфы до юзера именно по дефолту?

донести инфу до пользователя надо. если отдельно взятый редкий пользователь откажется ее читать, так он ССЗБ. неправда ли?

Флаг «отвечать на всё да» это возможность именно формата пакетов, или тулзы, их ставящей? ;)

ты пытаешься утянуть дискуссию в сторону.

если формально упереться в формат пакетов, то и слакварные tgz ничем не будут отличаться от deb/rpm. потому что и то и другое - суть простые архивы с парой файлов метаданных.

обрабатывать или не обрабатывать эти метаданные - задача программ а не «формата пакета»

соответственно мы обсуждаем то что в случае с rpm мы имеем:

* отсутствие debconf

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

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

>Тут совершенно другая ситуация описана. Проблемы были сразу после обновления до testing. Если у человека не сохранен конфиг, то он может на выходе получить непойми что и ответ на вопрос «а не сконвертить ли вам конфиг?» его никак не спасет.

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

> * отсутствие debconf

почему это является недостатком доказано не было

* то что в RPM майнтенеры практически нигде не пишут скриптов для постинсталляционных настроек.

когда надо пишут, случаев чтоб чего-то надо было крутить руками в rpm-based я не встречал, как ни странно это чаще встречается в deb-based

Ты уже поимел проблемы если ты не можешь разобраться из-за чего они и начал херачить дальше, то тебя уже ничего не спасет даже debconf. Как ответ «нет» так и ответ «да» в этой ситуации равноценен.

> почему это является недостатком доказано не было

потому что невозможно привлечь пользователя к разрешению проблемы. как пример показать ему лицензию.

как в RPM-дистрибутивах устанавливаются firmware на интеловые вайфаи?

когда надо пишут

но в дебиане пишут гораздо больше. о том и речь.

> потому что невозможно привлечь пользователя к разрешению проблемы. как пример показать ему лицензию.

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

как в RPM-дистрибутивах устанавливаются firmware на интеловые вайфаи?

тем что пользуюсь я ставятся через urpmi

но в дебиане пишут гораздо больше. о том и речь.

Да пусть хоть обпишутся. Нахуа писать скрипты ради скриптов?

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

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

тем что пользуюсь я ставятся через urpmi

мне все равно как, лицензию ты читал или нет?

Да пусть хоть обпишутся. Нахуа писать скрипты ради скриптов?

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

> донести инфу до пользователя надо. если отдельно взятый редкий пользователь откажется ее читать, так он ССЗБ. неправда ли?

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

ты пытаешься утянуть дискуссию в сторону.

Я её стараюсь привести туда, о чем она и есть — о сравнении _форматов_ deb и rpm, не?

обрабатывать или не обрабатывать эти метаданные - задача программ а не «формата пакета»

Чудно. А обрабатывающие программы мы уже давно начали обсуждать? ;)

в случае с rpm мы имеем:

* отсутствие debconf

Классно смотрится :)

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

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

мне все равно как, лицензию ты читал или нет?

Я бы её не читал даже если бы её мне показали. Не помню я выводилось там что-то или нет. Возможность вывести инфу после установки пакета имеется.

> Ага. Вот только мы только что упомянули флаг -y, который

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

Я её стараюсь привести туда, о чем она и есть — о сравнении _форматов_ deb и rpm, не?

такая дискуссия не имеет смысла. ну формат ну архив с метаданными.

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

как пример пользователю который делает SQL запрос по большому счету по барабану какой там формат на бакенде MyISAM InnoDB или еще что. ему важно что? чтобы запрос исполнился. вот разный набор фич он поймет: типа INSERT DELAYED _на движке MySQL_ не поддерживается InnoDB и если это пользователю надо, то он скажет «нуегонах этот InnoDB» а с другой стороны MyISAM не поддерживает FOREIGN'ы. что обсуждаем? движки или форматы?

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

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

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

в случае с deb мы в этом убеждены. если юзер поставил флаг «отвечать на все 'да'» то фактически он и на наш вопрос _ответ выдал_

rsync (*) (23.11.2009 14:50:46)

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

такая дискуссия не имеет смысла. ну формат ну архив с метаданными.

Это сабж, вообще-то. deb, а не aptitude. Ну ок.

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

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

Давай. yum, погнали. Ключ -y есть.

> Так и записываем

не надо так записывать. то что ты процитировал это был не аргумент в поддержку дебов, а аргумент про то что если человек ССЗБ то это его проблемы. если он отключает имеющуюся у него возможность не иметь проблемы и от этого имеет проблемы он ССЗБ

Это сабж, вообще-то.

сабж вообще об SRC

Давай. yum, погнали. Ключ -y есть.

и это плохо. ключ такой не нужен

> сабж вообще об SRC

Угу. Формате, дебиановском. И про «надстройку, использующую этот формат» вообще речь не шла, ты же сам приводил в пример deb, а не apt-*.

не надо так записывать. то что ты процитировал это был не аргумент в поддержку дебов, а аргумент про то что если человек ССЗБ то это его проблемы. если он отключает имеющуюся у него возможность не иметь проблемы и от этого имеет проблемы он ССЗБ

и это плохо. ключ такой не нужен

Тогда отвечай на начальный вопрос — как убедиться в том, что юзер ознакомился с вопросом, если установка автоматическая, или из гуя. В таком случае он тоже ССЗБ, что ставит пакеты не сидя над консолью?

>> Я спросил про подпись .deb. Не Contents-*, не .changes, а .deb

А смысл?

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

Я так понимаю, ответ на мой вопрос «нет, подписать .deb нельзя»?

> Смысл в том, чтобы взять 1 пакет и поставить его с проверкой подписи.

Между нами, девочками, в дебьяне ты не поставишь пакета из _удалённого_репозитория без проверки подписи, если сам ручками этого не отключишь. И даже с локального, если сам ручками включишь. Только я по-прежнему не понимаю, почему подпись должна быть _отдельно_ от пакета? Это какая-то эрпиэмная магия, выносить части пакета за его пределы и множить сущности в ФС без необходимости?

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

система debconf задает пользователю вопрос, получает _ОТВЕТ ОТ ПОЛЬЗОВАТЕЛЯ_ (если он настроил «всегда да» то он сам дурак) и на основании ответа от пользователя идет по тому или иному чойсу

В таком случае он тоже ССЗБ, что ставит пакеты не сидя над консолью?

а консоль тут при чем? пользователю никто не запрещает отвечать на поставленные вопросы в гуе

>Я так понимаю, ответ на мой вопрос «нет, подписать .deb нельзя»?

Насколько я понимаю главенствующую идеологию Debian, deb — это контейнер. А ставить надо только из репозитория. Кто не обеспечивает репозиторий для своих программ, а выкладывает голые deb, тот дурак и урод. Кто их ставит, тот тоже дурак. Может быть, даже вдвойне. :)

Реализация подписывания deb — совсем не rocket science. К тому же, если ее добавить, то ничего в прежней системе не поломается. Раз ее не сделали до сих пор, значит есть какие-то обоснования. Я вижу только те, которые абзацем выше привел. Это подтверждается также тем фактом, что в aptitude, apt-get нет возможности установить пакет из deb, а только из репозиториев. Наверняка есть куча тредов в -devel, где этот вопрос обсуждается.

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

Я знаю. Только причем тут это?

Только я по-прежнему не понимаю, почему подпись должна быть _отдельно_ от пакета?

Я тоже этого не понимаю, но в дебиане сделано именно так.

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

В RPM подпись является частью пакета.

> система debconf задает пользователю вопрос, получает _ОТВЕТ ОТ ПОЛЬЗОВАТЕЛЯ_ (если он настроил «всегда да» то он сам дурак) и на основании ответа от пользователя идет по тому или иному чойсу

Ок. Чем оно отличается от интерактивного вопроса скрипта из %pre, написанного в спеке рпм?

а консоль тут при чем? пользователю никто не запрещает отвечать на поставленные вопросы в гуе

А при том, что как обеспечить доведение этой инфы до пользователя в любом возможном гуе средствами deb/rpm?

> Насколько я понимаю главенствующую идеологию Debian, deb — это контейнер.

Насколько я понимаю, главенствующая идеология Debian - это костылестроение. Единственное исключение - apt-get. Это был прорыв, но это было 10 лет назад.

Реализация подписывания deb — совсем не rocket science. К тому же, если ее добавить, то ничего в прежней системе не поломается. Раз ее не сделали до сих пор, значит есть какие-тоНаверняка есть куча тредов в -devel, где этот вопрос обсуждается. обоснования. Я вижу только те, которые абзацем выше привел.

Приведенные абзацем выше доводы сводятся к фразе «ты дурак». Это, конечно, веский довод в споре, но ничего не объясняет.

Это подтверждается также тем фактом, что в aptitude, apt-get нет возможности установить пакет из deb, а только из репозиториев

И это доказывает что именно? И как в эту картину мира вписывается gdebi?

Наверняка есть куча тредов в -devel, где этот вопрос обсуждается.

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

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

А это не мои аргументы. Это мои предположения о том, почему подписи нет. Я, если честно, вообще не ставлю ничего их каких-то deb. :)

Но в целом и общем, что такого в том, что в качестве единицы установки предлагается репозиторий, а не *.deb? В большинстсве случаев этот *.deb затребует еще какой-нибудь *.deb. Начнешь ставить, откуда попало эти файлики — в итоге какой-нибудь из них скажет, мол, извини, друг, у тебя glibc старый или какой-нибудь скрипт свой выполнит криво. А если уж автор сподобился все правильно сделать с зависимостями (например, для Lenny собрать), то что ему стоит репозиторий организовать? Дело очень быстрое.

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

А это не мои аргументы.

Это вообще не аргументы. Это дешевые отмазки.

Но в целом и общем, что такого в том, что в качестве единицы установки предлагается репозиторий, а не *.deb?

В общем и целом, хочется иногда поставить один-два левых или самодельных пакета, не заморачиваясь на создание репозитория (да, я знаю про костыль с dpkg -i && apt-get install -f).

что ему стоит репозиторий организовать? Дело очень быстрое.

Не сказал бы. Блин, даже apt-rpm имел в составе скрипт «сделай репозиторий из этой свалки пакетов», а где такое в дебильяне?

Проблема том, что вся система управления пакетами дебиана сделана так. что всё, что не помещается в прокрустово ложе привычек разработчиков, просто игнорируется со словами «вам это не надо». А прокрустово ложе такое прокрустово.

>Не сказал бы. Блин, даже apt-rpm имел в составе скрипт «сделай репозиторий из этой свалки пакетов», а где такое в дебильяне?

Э-э, dpkg-scanpackages, не?

В общем и целом, хочется иногда поставить один-два левых или самодельных пакета, не заморачиваясь на создание репозитория (да, я знаю про костыль с dpkg -i && apt-get install -f).

Что касается deb и подписывания, то если бы попросили моего голоса в данном вопросе, то я бы не стал пока вписываться в петицию, потому что такие диверсионные установки меня не радуют. Зато сотни других подпишутся. Я если чего и ставлю не из репозитория, то пересобираю/перепакечиваю у себя, засовываю с локальный репозиторий. А тащить какую-то каку из интернета, которая вдруг скажет: «Эй, у тебя GTK 2.8, а я хочу GTK 2.10», я не буду. Вот Opera нашла силы добавить репозиторий, Skype тоже как-то раньше находил силы.

Проблема том, что вся система управления пакетами дебиана сделана так. что всё, что не помещается в прокрустово ложе привычек разработчиков, просто игнорируется со словами «вам это не надо». А прокрустово ложе такое прокрустово.

Понимаешь, в чем дело... Вот ты мог видеть эти споры где-то в местах, как ЛОР, где люди со стороны говорят, а надо такие вопросы в devel выносить, потому что никто кроме них... да. Все-таки надо знать, чье это мнение слушаешь. Какой-нибудь хрен с горы тебе отвечает, а ты его слушаешь. :) А кто знает, может быть есть какой-нибудь proposal по вопросу подписывания deb. В Debian же нет какого-то центра разработки. Мы говорим, почему *они* не сделают так или эдак, то к кому мы конкретно обращаемся? Можно назвать этих людей пофамильно? Кто нам должен? Я не могу. И так каждый может перекинуть с себя необходимость что-то сделать на каких-то мифических *их*.

О проблемах и запутанностях Debian в моментах сборки я осведомлен хоть чуть-чуть и знаю про оверхеды, которые накопились с годами. с другой стороны, я не сторонник ломать то, что построено и работает и имеет (что очень важно) документацию и накопленные навыки. Вот есть идея, то ее реализуешь, пропагандируешь, внедряешь. По мелочам — разговор с непосредственными ответственными за продукт.

> Вот ты мог видеть эти споры где-то в местах, как ЛОР, где люди со стороны говорят, а надо такие вопросы в devel выносить, потому что никто кроме них... да

Я говорил о том, что читал в debian-devel (или как там этот лист называется).

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

Да любой, кто знаком с кодовой базой apt/aptitude, может добавить инсталляцию из файла без проблем.

Кто нам должен?

Никто. Но в apt-rpm добавили инсталляцию с URL. Тоже ведь не обязаны были. В SmartPM она есть, вроде и в yum

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

Ты старый пользователь и привык уже. А я всего год как перешел, и мне эти проблемы режут глаз. Система управления пакетами дебиана уже давно созрела для массированной зачистки. Блин, сколько поколений там уже не убирали? dpkg, tasksel, apt-get, aptitude - 4 вроде?

> Ок. Чем оно отличается от интерактивного вопроса скрипта из %pre, написанного в спеке рпм?

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

А при том, что как обеспечить доведение этой инфы до пользователя в любом возможном гуе средствами deb/rpm?

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

> тем что кроме как в консоли пользователь этот вопрос не увидит

Как обходит эту проблему debconf? Так, чтобы DE/WM-независимо.

системы локализации этих вопросов нет

Не в курсе, как с этим у rpm-based, но это согласен записать в минусы, даже если так )

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

Для гуя 5, а для консоли? И пяти штук таки на всё хватает?

И тут не спец, но, наверное, такую проблему можно решить и универсальнее, перекинув гую stdout/stderr/stdin от того же yum, например, с небольшим анализом вывода, чтобы определить, что показывать юзеру, а что не обязательно. Но это всё тогда на совести гуя же, а формат пакетов тут вообще без разницы.

Насколько я понимаю, главенствующая идеология Debian - это костылестроение. Единственное исключение - apt-get. Это был прорыв, но это было 10 лет назад.

Кстати, возможность подписать deb есть. Однако это точно похоже на костыль. Причем, похоже, старый. Если глянуть в man dpkg, то можно узреть опцию --no-debsig, а если потом посмотреть в /etc/dpkg/dpkg.cfg, то можно увидеть, что проверка принудительно отключена. Это потому, что Debian не подписывает deb. Чтобы эта фишка работала, нужен пакет debsig-verify, с которым dpkg в паре работать будет. Если debsig-verify не установлен, то наличие или отсутствие опции никак не влияет на работу. Если поставить debsig-verify, от этой опции в dpkg.cfg приведет к тому, что будет тотальный отказ от установки неподписанных deb (и всех deb из репов Debian). Я проверил.

$ sudo dpkg -i xresprobe_0.4.22_i386.deb 
Проверка подлинности файла xresprobe_0.4.22_i386.deb...
debsig: Origin Signature check failed. This deb might not be signed.

dpkg: не удалось обработать параметр xresprobe_0.4.22_i386.deb (--install):
 Пакет xresprobe_0.4.22_i386.deb не проходит проверку подлинности!
При обработке следующих пакетов произошли ошибки:
 xresprobe_0.4.22_i386.deb

К тому же, внедренная подпись в deb никак не генерируется devscripts. Подписи только в .changes и .dsc добавляются. То есть ее надо специально генерировать чем-то сторонним (debsigs?). Есть стойкое ощущение, что эта концепция умерла. В man debsigs-verify идет речь о документе «Package Verification with dpkg: Implementation»: http://quux.org:70/devel/debian/debsigs.txt

Документ старый (2001 год), и мне кажется, что он более не актуален. Может быть, это были старые попытки внедрить подпись.

> Пардон, но я говорил о решении этого для любого возможного пакета в системе.

Для любого, в общем, можно пытаться, но, боюсь, только в рамках некоего «controlled environment» a-la виртуальные контейнеры. В противном случае накладные расходы на реализацию устремляются в бесконечность. Подумайте о том, что базы данных могут находиться вовне (на другой машине) и быть разделяемыми между несколькими клиентами, соответственно, простого восстановления файловой системы явно недостаточно.

> Только я по-прежнему не понимаю, почему подпись должна быть _отдельно_ от пакета? Это какая-то эрпиэмная магия, выносить части пакета за его пределы и множить сущности в ФС без необходимости?

С точностью до наоборот. Подпись и чексумма в RPM - составная часть пакета. В дебиане эта задача переложена на уровень выше - apt и прочих метапакетных менеджеров.

>Как обходит эту проблему debconf? Так, чтобы DE/WM-независимо.

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

Не в курсе, как с этим у rpm-based, но это согласен записать в минусы, даже если так )

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

И тут не спец, но, наверное, такую проблему можно решить и универсальнее, перекинув гую stdout/stderr/stdin от того же yum,

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

И при чем тут stdout/stderr/stdin гую, если смысл гуя в осмысленных интерактивных окнах, а не обертке к терминалу, в котором стандартные потоки показываются.

НЕНАВИСТЬ.

> Блин, даже apt-rpm имел в составе скрипт «сделай репозиторий из этой свалки пакетов», а где такое в дебильяне?

В дебиане это есть, и в использовании действительно проще, чем в rpm-based (AFAIR, [классический] apt/rpm пользуется репозиториями имени genbasedir, у которого довольно жесткие и сложные требования к входным данным).

> Как обходит эту проблему debconf? Так, чтобы DE/WM-независимо.

дебконф имеет обычные и GUI-фронтенды. всего-то делов

Для гуя 5, а для консоли? И пяти штук таки на всё хватает?

так одни и те же вопросы. там есть простой экран с уведомлением, простой экран с ошибкой, экран с выбором варианта (или вариантов) из списка, запроса пароля/текста, ответ да/нет, и по моему все (если ничего не забыл). В общем все случаи что нужны бывают при установке пакета перекрываются. debconf-devel(7) можно посмотреть.

такую проблему можно решить

фишка в том что в .deb эта проблема давно решена уже. а в yum ее еще _можно_ решить

>в случае rpmsave на каждом апгрейде мы теряем предыдущий save. в случае save на вопросе пользователю, этот вопрос задается один раз.

Хм. .rpmnew ни о чём не говорит?

Добавь мне на этапе установки пакета поддержку LDAP в sendmail-е. Проверь, что не было опечатки. С помощью тех самых скриптов.

> AFAIR, [классический] apt/rpm пользуется репозиториями имени genbasedir, у которого довольно жесткие и сложные требования к входным данным).

genbasedir - просто щастье по сравнению с dpkg-scan* и его друзьями.

>genbasedir - просто щастье по сравнению с dpkg-scan* и его друзьями.

Это был пример. Есть же и другие средства (навскидку): debarchiver, reprepro, apt-ftparchive, mini-dinstall. Все они имеют разную степень сложности. Репозитории в Debian могут быть упрощенными и сложными, для собственного пользования и для публичного вывешивания, с разными архитектурами и ветками обновременно, pool и т. д.

> Есть же и другие средства (навскидку): debarchiver, reprepro, apt-ftparchive, mini-dinstall.

Пробовал всё, кроме mini-dinstall. Осталось ощущение «ну нахрена мне-то все эти сложности?».

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

Я знаю это всё, и даже умею делать большую часть перечисленного :) (кроме репозиториев с ветками). Но, блин, инструменты не заслуживают лучшего эпитета, чем «ублюдочные». Или за ними стоит какая-то идеология, которую простые парни типа меня понять неспособны, а дебильяновцы не снисходят до объяснения.

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

То есть я правильно понимаю, даже если у меня будет где-то на третьей консоли (в смысле tty3) проходить установка пакетов, вопрос оттуда вылезет мне на первую в иксы, что бы там у меня не было запущено? В каком месте этот дополнительный слой реализуется, и как примерно выглядит?

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

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

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

И при чем тут stdout/stderr/stdin гую, если смысл гуя в осмысленных интерактивных окнах, а не обертке к терминалу, в котором стандартные потоки показываются.

НЕНАВИСТЬ.

Keep you rage in cool place ;) Тут мы проблемы не решаем, а обсуждаем. Это же не то, что без обсуждения лезть решать на практике ) Юм и потоки просто при том, что склепать один конкретный полнофункциональный гуй не проблема. И конечно не с тремя окошками терминала, а всё как надо. Другое дело универсальность решения, что делать если гуя нет, вот это да, проблема. И Пока что-то не могу представить технологии, гарантирующей требуемое взаимодействие с юзером в полном отрыве от всего остального, что только может использовать юзер.

>Я знаю это всё, и даже умею делать большую часть перечисленного :) (кроме репозиториев с ветками). Но, блин, инструменты не заслуживают лучшего эпитета, чем «ублюдочные». Или за ними стоит какая-то идеология, которую простые парни типа меня понять неспособны, а дебильяновцы не снисходят до объяснения.

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

Но если есть конкретные претензии, то почему бы не воспользоваться BTS (раздел Wishlist)?

> дебконф имеет обычные и GUI-фронтенды. всего-то делов

Заслуга дебконфа тут тогда только в меньшей костыльности их реализации. Для rpm с интерактивным %postin их же тоже можно склепать, разве что выбор из списка хз как отобразить по-человечески.

фишка в том что в .deb эта проблема давно решена уже. а в yum ее еще _можно_ решить

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

>Но, блин, инструменты не заслуживают лучшего эпитета, чем «ублюдочные». Или за ними стоит какая-то идеология, которую простые парни типа меня понять неспособны, а дебильяновцы не снисходят до объяснения.

Ну и вдогонку. Требования все-таки должны быть более предметными, чем просто «вы уроды и инструменты у вас уродские». Самое доступное место — это wishlist в BTS, почта авторов и пр. На самом деле все кирпичики для решения задач есть уже в базовой системе. Собрались пакетики, можно их в репозиторий переносить. Есть же уже cp, mv :). Надо индексы создать? Надо и эту задачу сделать. Нужно просто наиболее гармоничным способом все эти кусочки объединить (UNIX-way же). Но самое главное — это исчерпывающая документация. Проект без документации всегда у меня вызывал чувство его заброшенности и как-то интерес еще на первых этапах знакомства пропадает. Нет документации — меньше людей будет пользоваться. Меньше людей пользуется — низкая популярность. Проект становится маргинальным.

> Не в ублюдочности дело, а в том, что как-то нет единоначалия в проектировании этих инструментов.

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

Но если есть конкретные претензии, то почему бы не воспользоваться BTS (раздел Wishlist)?

Почти все свои пожелания я находил в архивах с резолюцией «ПНХ» :) Видимо, они противоречат какой-то глубокой идеологии, которой я не понимаю. А писать патчи для apt-get - это проще сделать скрипт на коленке.

> Для rpm с интерактивным %postin их же тоже можно склепать

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

так что «можно склепать» = нереализованная = отсутствующая функциональность

Если проблема долго висит в статусе «можно решить», то обычно она не такая уж и проблема.

если «можно решить» приведет к переделки тонн софта, то проблема может висеть сколь угодно долго. «можно решить» тут почти равно «нельзя решить»

я очень сомневаюсь что над RPM когда-либо появится debconf

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

в пятый раз приведу в пример - интеловый фирмварь для вайфаев. лицензия требует быть показанной пользователю.

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

А оно там кому-то надо? Ни разу нигде не видел жалобы виндоюзеров на отсутствие пакетного менеджера ;)

так что «можно склепать» = нереализованная = отсутствующая функциональность

нереализованная = (отсутствующая | невостребованная) функциональность. Так точнее.

если «можно решить» приведет к переделки тонн софта, то проблема может висеть сколь угодно долго. «можно решить» тут почти равно «нельзя решить»

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

я очень сомневаюсь что над RPM когда-либо появится debconf

_deb_conf точно не появится ) А так кто знает.

в пятый раз приведу в пример - интеловый фирмварь для вайфаев. лицензия требует быть показанной пользователю.

Прекрасно помню. Даже если не трогать вопрос, почему этого не требуют все остальные лицензии в системе (с ними ведь точно так же можно не согласиться, правда?), прокомментируйте тогда пожалуйста вот это:

Q2. We do not have any type of a «click through» license for each package that is installed, and our packages aren't typically used to create a new OS image.

A2. The important point is to make sure that the end user is notified that the firmware component is governed by an Intel license and provided with a copy of the license terms prior to downloading or using the software. In the event that the package is automatically downloaded by a package update tool, and that tool provides no provision to indicate to the user that they are installing software that is covered by such a license, following A1.2 and A1.3 above is sufficient.

Особенно вторую часть ответа. Пункты 1.2 и 1.3 выше содержат только требования по части расположения текста и упоминания лицензии в системе и описании пакета. Это же оно, нет?

http://www.intel.com/support/wireless/wlan/sb/cs-016675.htm

Frequently asked questions on the firmware license for Linux

> в пятый раз приведу в пример - интеловый фирмварь для вайфаев. лицензия требует быть показанной пользователю.

Решено в Сюзе (по крайней мере, для Нвидиевых драйверов). Как - не знаю, но, судя по всему, штатно (в смысле, без особого костыля именно для этого пакета).

Так нвидиевские закрытые в той же федоре тоже молча ставятся.

Так нвидиевские закрытые в той же федоре тоже молча ставятся

В том-то и компот, что в Сусе (по крайней мере, в OpenSUSE 9.2 (?) и 10.x, с прочими не сталкивался) они ставятся zypper'ом (и соответствующим yast'овым GUI front-end'ом) не молча, а с демонстрацией лицензионного соглашения. С учетом того, что RPM все-таки задумывался для автоматического неинтерактивного развертывания ПО, это произвело на меня неприятное впечатление. У zypper'а, правда, есть опция для автоответа на все вопросы согласием, но осадок остался

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