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

yum-plugin-protect-packages

yum-plugin-post-transaction-actions

Черт, я же слышал об этом сотню раз, но все как-то краем сознания. Спасибо за напоминание

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

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

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

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

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

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

А смысл?

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

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

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

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

> kernel-devel, gcc

У меня они оба еще для akmod-nvidia. Ладно, не у всех это проприетарное творение стоит, многие могут обойтись без dkms/akmods. Но тут вон похоже есть плагин к yum, куда можно повесить команду рекомпиляции при обновлении ведра, а при обновлении вбокса он это опять же, сам и сделает — если эта пара пакетов критична, и надо полную автоматизацию. Результат тот же, не?

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

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

Не за что, надо было записывать ;) И там еще много чего вкусного есть, `yum search yum` )

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

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

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

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

насчет «обратного поведения» не припомню. Заканчивается правкой конфига ручками + apt-get -f install. Либо dpkg --purge.

Насчет обратного имел в виду обрывать установку при сбое скрипта. Это вроде бы дефолтное поведение.

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

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

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

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

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

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

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

> MS-DOS нынче не является частью Windows
Ну и что? Всякие костыли типа букв дисков и обратных слешей остались, как и основные консольные команды
> крошечный закос под Unix
Вот про него я в своем сообщении и напомнил. Хотя если честно, Unix V7/x86 выглядит местами пострашнее DOS, хоть и многозадачный. Хотя это я наверное не умею его готовить.

> Настролько странноватый, что на нём без сторонних средств невозможно написать сколь-нибудь полезные скрипты
На баше без GNU-утилит ты тоже ничего полезного не напишешь. Другое дело, что все эти проги похорошему должны быть изначально в ОС, а не скачиваться из разных мест по одной.
Но тем не менее, я делал на CMD довольно полезные скрипты, когда мне приходилось работать с вантузом... И всё же неплохо бы посмотреть функции виндовой консоли. Оказывается, там есть fc (аналог diff), for (хотя отличающийся от юниксового for, но позволяющий одну команду применить к группе файлов)
> Поэтому остаётся хайтек в виде скриншотов "Проводника", зачем-то помещённых сначала в ворд
Можно с тем же успехом делать скриншоты наутилуса и помещать в документ опенофиса. Некоторые вообще догадываются класть монитор на сканер, чтоб скриншот сделать. Это не отменяет наличия в винде команды dir... А потом можно открыть полученный файл блокнотом, выставить шрифт terminal (чтоб видеть русские буквы) и распечатать.
Интересно, а в голой винде хоть один аналог iconv есть?

Интересно, а в голой винде хоть один аналог iconv есть?

В голой — вряд ли. Зато есть iconv для Windows (google gnuwin32)

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

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

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

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

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

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

Ну это да, но вообще говоря, не на своем компе наверное этим заниматься не стоит (добавлением каких-то программ), а на своем можно и нормальную ОС поставить.

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

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

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

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

> Тут юзеру не надо следить
Вот как раз тут юзеру надо следить вдвойне! Просто сравни. Человек должен знать что:
а) пакет поставился. Значит работает. В гуях кнопка "сделай мне зае..сь".
б) пакет не поставился. Искать причину.
в) оперативный фидбэк разработчику/звонок в саппорт. В гуях ткнуть кнопку "проблема".
или
а) пакет поставился, но НИКАКОЙ гарантии.
б) Всегда сидеть над консолью и вникать в процесс..
в) г-но ваш линукс - ничего не работает как должно работать.

Что в конечном итоге правильнее? скрыть проблему или все же явно ее высветить?


> Если делить на пакеты, то это вбоксовцам надо было бы компилить их еще раза в три больше.
Оверхед только в дополнительном пакете, который по прежднему делает то, что и делал - компилирует модуль. Но с нормальным ПРЕДСКАЗУЕМЫМ результатом.

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

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

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

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

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

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

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

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

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

Уж как минимум если высвечивать и спрашивать, если что, всё по-человечески, «средний юзер» с такой системы бегом побежит. Так что черно-белый вариант не получится. Лучший вариант, имхо — что-то вроде достаточно функционального гуя, который и лиц. соглашение, если надо, выведет, и об ошибке в процессе установки скажет, и т.п. Но его еще сделать надо, в то время как в консоли уже сто лет всё есть, так что хоть иногда туда забегать всё-таки желательно, как компромисс. Тем более что гуй всё-таки всех проблем не решит. А если gui в линуксе станет обычно функциональнее, чем cli, я такого линукса не хочу ;)

Оверхед только в дополнительном пакете, который по прежднему делает то, что и делал - компилирует модуль. Но с нормальным ПРЕДСКАЗУЕМЫМ результатом.

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

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

А это не мои аргументы. Это мои предположения о том, почему подписи нет. Я, если честно, вообще не ставлю ничего их каких-то 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 вроде?

еще раз: непредсказуемость в сокрытии проблемы.

> еще раз: непредсказуемость в сокрытии проблемы

Проблемы с выполнением postin скриптов? Консоль проблему не скроет точно, yum, как я понимаю, в любом случае напишет что-то вроде «postin scriptlet failed». Что тут сделает гуй — это уже на совести самого гуя, но, по-хорошему, сообщение об ошибке отобразить должен. А там уже юзеру все равно разбираться, что с полностью отмененной установкой (вряд ли он просто от неё откажется), что с частичной, со сбойнувшим скриптом.

> Ок. Чем оно отличается от интерактивного вопроса скрипта из %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 виртуальные контейнеры. В противном случае накладные расходы на реализацию устремляются в бесконечность. Подумайте о том, что базы данных могут находиться вовне (на другой машине) и быть разделяемыми между несколькими клиентами, соответственно, простого восстановления файловой системы явно недостаточно.

> Просто ты как не осиливал BSD make так и не осиливаешь.

Не надо меня лечить по телефону, ага? Конкретно во фряшных .mk'шках столько галимой императивщины (в Makefile'ах, ага, самое место :/), что волосы дыбом встают. А хачить собственно bsdmake пришлось против пары каких-то сравнительно мелких, но неприятных приколов.

> Ах ё, так вот оно что. А мы тут уже n-ю страницу о технических преимуществах и недостатках вариантов сборки, как правильно, и как неправильно.

Нужно понимать одну простую вещь. Саппорт - это *всегда* платное предприятие. За здорово живёшь можно только в IRC и форумах потрепаться, и, *может быть*, получить решение. А можно и не получить, но кого это .... , форумы - это ж *не саппорт* , никто никому ничего не должен.

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

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

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

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

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

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

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

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

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

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

НЕНАВИСТЬ.

> Но тут вон похоже есть плагин к yum, куда можно повесить команду рекомпиляции при обновлении ведра, а при обновлении вбокса он это опять же, сам и сделает — если эта пара пакетов критична, и надо полную автоматизацию. Результат тот же, не?

Вероятно, с точки зрения особенностей реализации RPM - это самое внятное решения (если я Вас правильно понял, это аналог упомянутых мной posttrans-скриптов, но на уровне yum'а). Можно ли осуществлять автоматическую доустановку требуемых пакетов на этом этапе?

>Нужно понимать одну простую вещь. Саппорт - это *всегда* платное предприятие. За здорово живёшь можно только в IRC и форумах потрепаться, и, *может быть*, получить решение. А можно и не получить, но кого это .... , форумы - это ж *не саппорт* , никто никому ничего не должен.

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

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

Судя по всему, самое адекватное для пользователя упомянутой кнопки - это по окончании операции сделать некую минимальную нотификацию «Всё з..лось!» или «Ой, не шмогла!» с краткими указаниями, что именно не шмогла, и где и как взять подробный лог происходившего. Захочет - посмотрит сам, не захочет - скопирует текст с экрана (гы-гы, смотри тему про список файлов :) ), приаттачит лог, отправит в саппорт.

>Вероятно, с точки зрения особенностей реализации RPM - это самое внятное решения

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

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

Самое адекватное, делать все это в рамках запуска самой программы, а не в рамках процесса инсталляции.

> Поэтому грамотно построеная система вполне может обойтись саппортом в виде бесплатного форума

Алексей, зависит от уймы факторов, начиная от scope продукта и целевой аудитории (продукты от айтишников для айтишников же - они при прочих равных проще в обслуживании, чем для домохозяек или там продавцов недвижимости :) ), до политических и имиджевых факторов. Типа, продуктовая линейка без колл-центра, - это и не продукты вовсе, а так, поделухи. А если есть колл-центр, то можете быть уверенным, заметная часть пользователей предпочтёт позвонить туда со своим вопросам, чем выискивать вопрос в интернетных форумах. Чистая психология, никакой технологии.

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

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

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

«Не мы такие - жизнь такая, нех.. танцевать!»

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

Для некоторых из таких «недостатков» вендоры чуть ни повсеместно лепят свои вендор-специфичные затычки (например, в yast'е, я так понял, уже есть штатный метод при/перед установкой некоего пакета продемонстрировать пользователю EULA, если это нужно изготовителю данного пакета). Вероятно, на каком-то этапе эти «затычки» будут унифицированы и внедрены везде, а пока, извините, имеем то, что имеем - если хочешь сервиса чуть большего, чем предоставляется «обычным метапакетным менеджером» - сделай свой, прилепи расширение к твоему любимому менеджеру, итп.

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

> саппортом в виде бесплатного форума

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

Дело не в самом BSD make, а в той фигне, что понаписали на его основе, под названием 'ports'.

>goodwill (русское "добрая воля" не вполне адекватный перевод)

Доброжелательность?

> Как обходит эту проблему 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 ;) Тут мы проблемы не решаем, а обсуждаем. Это же не то, что без обсуждения лезть решать на практике ) Юм и потоки просто при том, что склепать один конкретный полнофункциональный гуй не проблема. И конечно не с тремя окошками терминала, а всё как надо. Другое дело универсальность решения, что делать если гуя нет, вот это да, проблема. И Пока что-то не могу представить технологии, гарантирующей требуемое взаимодействие с юзером в полном отрыве от всего остального, что только может использовать юзер.