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

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

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

>А почему тогда при apt-get update ко мне все еще приезжают полные копии пакетов, а когда делаю zypper update, то дельты и патчи? ЧЯДНТ?

Используешь не тот менеджер пакетов. Cupt тебе в руки. Или debdelta-upgrade. Читай описания пакетов. (И не apt-get update, а 'apt-get upgrade').

>не прервет инсталляцию.

Это очень сильно усложняет скрипты

Другой вопрос в том, что и скрипты при этом (возможно) не сделают то, что задумано, но от такого ничто не спасет, AFAIU

а вот это как раз в 99% не страшно. Собственно, поэтому в 99% случаях скрипты и не нужны.

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

Там в условии печать из проводника, что ж они еще могут предложить )

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

Интересно, спасибо.

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

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

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

Думаю, обычно догадываются, но накой им тратить силы и время на освоение отвертки, если и так всё пока работает. А что когда-то перестанет, так это еще вилами по воде писано.

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

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

> не просьбу прислать пару строчек с HTML страницы присылали в письме doc, в котором был tiff-файл, полученный сканированием распечатанного скриншота, на котором во весь экран был открыт браузер

Выглядит как цитата с башорга. Ппц.

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

Спасибо, добавил в закладки.
И разослал знакомым вендузятникам с вопросом "Ты знал?" ;)

Нене, такое бывает, подтверждаю.

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

А то, что этого и кодер не обеспечит на 100%, это ничего? ;)

> Для этого есть напоминалки как при установке, так и при запуске самого продукта.

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

при чем тут школа? из зачем тебе печатать именно через gui? попробуй тогда список разпечатать через наутилус или дельфин

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

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

$ man chcp
Ничего про chcp в руководстве нет

Палимся...

Точно, палитесь :)

> См. cupt snapshots.

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

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

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

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

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

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

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

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

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

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

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

> Точно, палитесь :)

Палиться так палиться. http://www.windowsfaq.ru/content/view/249/57/

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

«Requires: dkms» ему в спек

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

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

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

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

Там в условии печать из проводника, что ж они еще могут предложить )

А как «обычный юзер»(ТМ) может ещё посмотреть содержимое папки? Есть другой файлменеджер в Венде «искаропки»?

[quote]«Requires: dkms» ему в спек[/quote]

Кстати да, это ж я про закрытую версию. А для OSE вроде бы так и есть:

[code]$ yum search akmod-VirtualBox akmod-VirtualBox-OSE.x86_64 : Akmod package for VirtualBox-OSE kernel module(s)[/code]

Я о том же, что проводник единственный вариант, и таких средств у него нет. Хотя вообще не помню, если там нажать ctrl+c на файле, а потом ctrl+v в любом текстовом редакторе, так разве не прокатит?

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

> Есть другой файлменеджер в Венде «искаропки»?

Есть. cmd.exe

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

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

Кстати да, это ж я про закрытую версию

И я про нее же, к открытой претензий никаких

>при чем тут школа? из зачем тебе печатать именно через gui? попробуй тогда список разпечатать через наутилус или дельфин

Попробуй сначала найти наутилус или дельфин у меня на компьютере. А вот ls есть в любом Unix'е, как и explorer в любой винде. Это - стандартные средства.

>А то, что этого и кодер не обеспечит на 100%, это ничего? ;)

да, это нормально. Кодер сам ничего в процедуру инсталляции не вносит, а пакажер должен трезво оценивать свои возможности и принимать правильное решение.

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

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

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

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

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

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

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

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

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

так вот поэтому и не нужно портить то, что уже и так есть и работает.

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

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

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

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

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

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

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

> /etc/config.rpmsave

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

cmd.exe тоже есть в любой венде

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

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

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

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

rpm -Uvh vbox* && ууухмегаскрипт

Интересно как же работает dkms в той же мандриве. Проприетарные модули сами собираются при установке и после обновления ядра.

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

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

>> Кто сказал, что плагины двоичные? Кто сказал, что они автоматом цепляются из директории, а не прописываются в конфигах?

> ну давай пример пиджин, мозилла, инкскейп, гип - везде просто сошки или скрипты

lighttpd + lighttpd-mod-*
Плагин должен быть прописан в конфиге.

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

Разумеется. Начерта его ставить, если он не будет запущен?

> Сконфигурил - запускай.

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

> а с какого? В меню gdm появился еще один wm. Выбирай и наслаждайся...

А с какого я должен выбирать _из гдм_? А если у меня по дефолту ?дм, не умеющий менять самого себя на что-то другое? Не говоря уже о том, что еще иксы могут не стоять. Это всё равно, что предлагать менять $EDITOR из $EDITOR'а же.


> Написать сообщение при установке, мол, хорошо бы вам прямо тут для сборки модулей дать команду vmware-config.pl или service vbox build. Можно при запуске самого виртуала выдать сообщение, мол модулечки не собраны...

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

> И вот в части виртуалок у них оно грохнется. И пойди, проверь, что и где поставилось или нет.

Хых, для этого скрипты должны быть идемпотентные. Да, это Высокое Искусство - писать такие скрипты :).

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

> И я про нее же, к открытой претензий никаких

А у неё еще и спек есть? Или про чей шла речь?

>cmd.exe тоже есть в любой венде

Но он не гибок и ему не учат. Поэтому пусть лучше в школах учат Linux'у.

Да и детишки не будут квадратными глазами потом смотреть на новую ОС или новый WM. А то ведь сейчас обучение такое - если привычного ярлычка на рабочем столе нет, то глаза наливаются праведной яростью: "в вашем б..дском линуксе даже программ нормальных нет". Нужно показывать всего по-немножку и объяснять общие принципы, не зацикливаясь на конкретике. Тогда бывшие школьники и ярлычок найдут и программу поставят из какого-нибудь Synaptic'а и работу сделают, а не будут зацикленными аутистами, натренерованными действовать по привычной схеме.

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

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

> да, это нормально. Кодер сам ничего в процедуру инсталляции не вносит, а пакажер должен трезво оценивать свои возможности и принимать правильное решение.

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