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

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

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

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

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

> На русской Windows до XP включительно (насчет более поздних не уверен) половина текста в net.txt будет кракозяблами.

NB: оффтопить так оффтопить :)

man chcp. Палимся...

> * 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 нет. Ископаемое такое ископаемое.

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

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

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

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

>dir > list.txt
>copy list.txt prn

Ну вы под..бали уже. Во-первых ваш пример не работает, только что проверил. А во-вторых, а если по почте отправить? А убрать на ходу расширение txt, а отправить рекурсивный список, а отправить только список файлов, содержащих определённый текст?

ls | sed -e 's/\.txt$//' | mail -s "List of files" box@mailserver.com

find . -print | mail -s "List of files" box@mailserver.com

grep -R deb * | cut -d: -f1 | uniq | mail -s "List of files" box@mailserver.com

Давайте перестанем упражняться в троллинге. Если в винде и есть способы распечатать список файлов в каталоге, то 1. они убоги, 2. не являются для неё родными, 3. не являются эффективными.

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

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

Когда детей учат на винде, они просто не догадываются о существовании других подходов, они становятся простыми потребителями "программных продуктов". Это необратимо калечит детские мозги. Дурное дело - нехитрое, мышекликанию можно и в Linux'е научить. Да и чего там учить, описание элементов управления и способов воздействия на них укладывается в два-три урока, познакомить с подлинными возможностями табличного процессора - тоже пара уроков (а то мышекликатели часто даже не догадываются, что в Excel'е чуть ли не бухгалтерию вести можно). А вот научить думать и самообучаться гораздо тяжелее, чем научить выкладывать за всё деньги.

По большому счёту, ни для чего больше, кроме тривиальных и _очевидных_ действий и нотификаций 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.

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

> 1. они убоги

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

2. не являются для неё родными

являются

3. не являются эффективными.

почему это?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/etc/config.rpmsave

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

Вы будете смеяться, но это рекомендованный способ: http://support.microsoft.com/kb/196628/ru

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

google «%config(noreplace)»

> мышекликатели часто даже не догадываются, что в Excel'е чуть ли не бухгалтерию вести можно

Не то что бухгалтерию, а и, например, матстатистику на уровне 3-4 курса техвуза, я гарантирую это ) Другое дело, накой шурупы молотком забивать.

есть ли в рпм нормальный способ выполнить скрипты, не оборвав установку в случае чего

Если в конце скриптов будет явно прописана строка «exit 0», то установка не оборвется

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

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

>> 1. они убоги

>для извратов есть powershell, если надо читай доку по нему.

Не пытайся мне доказать, что его преподают в школе. Это всё равно, что сказать, что для извратов в Linux есть Perl.

>> 2. не являются для неё родными

>являются

Ога, dir > prn растёт ногами из MS-DOS, а тот в свою очередь - из Unix. А где же родной и удобный мышекликательный гуй? Ведь всего-то и надо, что распечатать список файлов.

>> 3. не являются эффективными.

>почему это?

Покачану. Если в школе преподаётся только мышиная возня, а Power Shell или просто shell не преподаются, то соответственно и все усвоенные приёмы работы за компьютером не являются эффективными во для всех случаев.

Уж лучше пусть будут хорошо учить плохому Linux'у, чем плохо - хорошей винде.

> Не то что бухгалтерию, а и, например, матстатистику на уровне 3-4 курса техвуза, я гарантирую это ) Другое дело, накой шурупы молотком забивать.

Потому что смежники не догадываются о существовании отвёртки.

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

> Ога, dir > prn растёт ногами из MS-DOS, а тот в свою очередь - из Unix

Насколько я помню, нет. Первоисточник, как уже сказали, CP/M, а дальше - что-то DEC'овское, AFAIR (VMS?).

>Вы будете смеяться, но это рекомендованный способ: http://support.microsoft.com/kb/196628/ru

Это было бы смешно, если бы не было так грустно. На практике мне встречались альтернативно одарённые люди, который не просьбу прислать пару строчек с HTML страницы присылали в письме doc, в котором был tiff-файл, полученный сканированием распечатанного скриншота, на котором во весь экран был открыт браузер. Самое ужасное, что пытаться научить этих людей делать правильно практически невозможно, их мозг съеден микрософтом.

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

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

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

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

yum --help | grep downgrade
downgrade      downgrade a package

> Если в конце скриптов будет явно прописана строка «exit 0», то установка не оборвется

Нет, AFAIR, в скриптах /bin/sh запускается с -e. Первый же ненулевой код возврата означает прерывание скрипта

>Безбажно это как? Обеспечить сборку модуля даже на несовместимом с кодом программы gcc? Или что тут можно назвать именно багом по вине сборщика?

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

> downgrade downgrade a package

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

>Не то что бухгалтерию, а и, например, матстатистику на уровне 3-4 курса техвуза, я гарантирую это )

Да хоть бы о функции СУММ узнали бы, и то уже красота была бы.

>Другое дело, накой шурупы молотком забивать.

Затем, чтобы не забивать шурупы микроскопом. Всё-таки в Excel'е или Calc'е можно делать сильно больше, чем составлять таблицы. А то можно увидеть людей, считающих на настольном калькуляторе сидя перед распахнутым на весь экран окном Excel и вписывающих туда результаты вычислений.

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

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

>Насколько я помню, нет. Первоисточник, как уже сказали, CP/M, а дальше - что-то DEC'овское, AFAIR (VMS?).

Я же и сказал это. Каталоги и передача текстового файла по потоку в MS-DOS появилась в версии 2.0 и была сделана именно под влиянием идей Unix. До этого ни каталогов, ни пернаправления, ни специальных устройств не было.

VMS - это уже в NT-шной винде появилось, поэтому dir > prn тут вообще не при чём.

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

Кстати, да, и работает надёжнее, и отлаживать проще. Ну, за исключением того, что упомянуть в документации - это не решение :)

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

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

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

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

Нет, AFAIR, в скриптах /bin/sh запускается с -e. Первый же ненулевой код возврата означает прерывание скрипта

Прямо сейчас не вспомню, где вычитал (то ли в «max. rpm», то ли в Федориных гайдлайнах), примерно следующее:

potentially_unsafe_command || :
potentially_unsafe_command2 || :
exit 0