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

> Свой первый PKGBUILD я за 5 минут написал, после просмотра примера. С deb возился половину дня, в конце концов, результат тоже показался мне сделаным через жопу.

Ну логично — системы, ориентированные на установку из сорцов, имеют простую и понятную систему для этого. А для пакетников локальная сборка пакета всё-таки далеко не рядовая задача же. Что примерно компенсируется легкостью и скоростью yum update вместо emerge world.

>А для пакетников локальная сборка пакета всё-таки далеко не рядовая задача же.

с RPM эта нерядовая задача решается за 15 минут.

Далеко не у всех, я гарантирую это ) См. выше про полдня. И не то чтобы руки сильно кривые, просто с полного нуля понять, даже с объяснениями и примерами, структуру спека, что там должно быть, и что оно должно делать, и потом заставить его всё собраться без ошибок — задача далеко не на 15 минут. Ну а сделать всё как надо, прочитав хаутушек кб так на 600-800 — тем более.

>Далеко не у всех, я гарантирую это ) См. выше про полдня. И не то чтобы руки сильно кривые, просто с полного нуля понять, даже с объяснениями и примерами, структуру спека, что там должно быть, и что оно должно делать, и потом заставить его всё собраться без ошибок — задача далеко не на 15 минут.

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

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

Не, ну если уж на то пошло, то первый раз я этот пакет ставил вообще из сюсевского srpm тупо через rpm-rebuild кажется, и вообще не заглядывая ни в какие спеки, и ничего не меняя. Работало. Падало, правда, иногда, но в общем работало ) А если уж лезть редактить спеку, то как минимум надо знать, что означает всё то, что ты там видишь, имхо )

Тем более на название и версию в моем случае вообще начхать, кто туда смотреть-то будет. А вот список и пути файлов, разрешения, доп. конфиги, патчи, pre и post-скрипты, вопросы при обнаружении «фашистской политики сборки», или как там её — это всё совсем не 15 минут )

>Не, ну если уж на то пошло, то первый раз я этот пакет ставил вообще из сюсевского srpm тупо через rpm-rebuild кажется, и вообще не заглядывая ни в какие спеки, и ничего не меняя.

нет. ну это означает, что у тебя уже есть src.rpm. Тогда, понятно,

rpm --rebuild xxx.src.rpm и готово.

Я имел в виду ситуацию, когда спека нет. Есть только тарбол с сайта программы и в нем спек не лежит.

А если уж лезть редактить спеку, то как минимум надо знать, что означает всё то, что ты там видишь, имхо )

Ну в нем все очевидно.

Name: наверное, тут имя

Version: а тут вероятно версия.

%files

неужто список файлов?

Тем более на название и версию в моем случае вообще начхать, кто туда смотреть-то будет.

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

А вот список и пути файлов, разрешения, доп. конфиги, патчи, pre и post-скрипты, вопросы при обнаружении «фашистской политики сборки», или как там её — это всё совсем не 15 минут

Ну, вопросы при обнаружении «фашистской политики сборки», это травмы альта, остальное как раз 15 минут.

> нет. ну это означает, что у тебя уже есть src.rpm. Тогда, понятно, rpm --rebuild xxx.src.rpm и готово.

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

Ну в нем все очевидно.

Там обычно бывает намного больше слов, чем только name, version и %files ) Которые имеют немного большую важность для нормальной установки и работы софтины, чем имя и версия. И с нуля понять и проверить корректность их всех дело небыстрое. А если не проверять, то да, rpm --rebuild чей_угодно_первый_попавшийся_src.rpm и всё, зачем те спеки )

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

Ну и я про то же. Да даже от этой же, только для другого дистра, при нулевых знаниях о сборке софта в линуксе вообще (ну за исключением варианта ./configure && make && make install ;)

Ну, вопросы при обнаружении «фашистской политики сборки», это травмы альта

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

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

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

Там обычно бывает намного больше слов, чем только name, version и %files ) Которые имеют немного большую важность для нормальной установки и работы софтины, чем имя и версия.

90% программ собираются configure make и make install

Вот это и забито в спеке между названием и %files

И с нуля понять и проверить корректность их всех дело небыстрое. А если не проверять, то да, rpm --rebuild чей_угодно_первый_попавшийся_src.rpm и всё, зачем те спеки )

Ну если собралось - хорошо. Если нет, поправил названия и опять хорошо. ;)

Это были мои травмы, когда я не перечислил все собранные файлы в спеке )

это бывает. но дерево установки же сохраняется. вывод find или tree посмотрел и внес исправления. и все...

> А что такого? Проблемы переносимости спеков между дистрами только в специфичных макросах и названиях пакетов в зависимостях

Как минимум еще пути в %install/%files и скрипты в pre(un) и post(un). Это только то, что мне попалось, полные доки по сборке не изучал.

90% программ собираются configure make и make install

Была бы задача тупо получить рабочий бинарник, зачем эти пакеты вообще нужны были? ) Скачал .tar.bz2, одну команду отдал и вуаля.

Ну если собралось - хорошо. Если нет, поправил названия и опять хорошо. ;)

Со временем начинает хотеться большего. Не просто собранного пакета, а еще и собранного более-менее как надо ) В конце-концов, а что делать, если покрасноглазить хочется, но гента выглядит немного overkill'ом )

это бывает. но дерево установки же сохраняется. вывод find или tree посмотрел и внес исправления. и все...

Так я ж не против. Инфа есть, гугель есть, хаутушки есть, и всё такое. Просто каждая такая вещь отнимает по достаточному куску времени, чтобы в сумме ушел не один час (ну не непрерывно, конечно).

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

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

Разговор был не о том, а о сравнительном времени на поиск нужного .src.rpm и нужного гита с исходниками и патчами.

>Как минимум еще пути в %install/%files и скрипты в pre(un) и post(un). Это только то, что мне попалось, полные доки по сборке не изучал.

пути везде одинаковые. %_prefix %_bindir etc

Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

Была бы задача тупо получить рабочий бинарник, зачем эти пакеты вообще нужны были? ) Скачал .tar.bz2, одну команду отдал и вуаля.

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

Со временем начинает хотеться большего. Не просто собранного пакета, а еще и собранного более-менее как надо ) В конце-концов, а что делать, если покрасноглазить хочется, но гента выглядит немного overkill'ом )

ну это совсем другое дело! нравится - копай.

Так я ж не против. Инфа есть, гугель есть, хаутушки есть, и всё такое. Просто каждая такая вещь отнимает по достаточному куску времени, чтобы в сумме ушел не один час (ну не непрерывно, конечно).

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

Разговор был не о том, а о сравнительном времени на поиск нужного .src.rpm и нужного гита с исходниками и патчами.

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

Со временем начинает хотеться большего

Тогда стоит вложить немного времени в изучение "Maximum RPM"

> Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

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

> пути везде одинаковые. %_prefix %_bindir etc

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

Скрипты имхо в идеале не нужны. То есть если и нужны, то в самом минимуме. Навскидку только ядро с его скриптом мкинит и прописью в груб приходит в голову.

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

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

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

ну это совсем другое дело! нравится - копай.

Не то чтобы прям очень нравится, был бы выбор — врядли бы этим занимался, по крайней мере сейчас. Но софтину хочется, в репах нет, сходу ставить сильно отличающийся .srpm не совсем Ъ, так что и выбора нет )

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

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

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

Там было всё же другое, насчет зачем пилить функциональность пакетов с сорцами, как в сабже, чтобы удобнее было таскать оттуда патчи и т.д., если вроде бы кошернее будет делать это в системе типа git.

Эту*

> Тогда стоит вложить немного времени в изучение «Maximum RPM»

Это находил. Но, как правильно написано в названии, тут уже скорее не больше а максимум )

>Так я про это же — чтобы получить не только что-то собранное и кое-как взлетающее, а то, что надо, `rpmbuild --rebuld` вполне может оказаться недостаточно.

Все верно. Что rpm, что deb — надо порой довольно долго править руками, чтобы было *правильно*. Вон тут кто-то недавно спрашивал, как правильно поставить gcc ну очень старой версии в Debian из deb. А вот правильно — это пересобирать, потому что не только зависимости изменились, но и вся инфраструктура. Скриптовую часть надо основательно проверять, там надо update-alternatives делать и прочие вещи, разыменовывать бинарники из gcc по версиям, делать линки. А другим каким-то пакетам надо и права переназначать, и группы создавать или добавлять в группы, демоны, обновления кеша шрифтов, кеша иконок для GTK, добавить лицензии, правильно создать структуру каталогов, докинуть нужные скрипты, поменять артворк, разбить на пакеты. Да масса всего. Я согласен, что именно *правильная* сборка — это не 15 минут, а гораздо больше. Однако чаще всего старый /debian выручает — только зависимости чуть подправить, changelog Debian, несколько мелочей, опции конфигурации — и можно на пересборку отправлять. А вот сопровождающим надо за каждой мелочью следить всегда, да, учитывая, что еще трах с архитектурами добавляется (некоторые пакеты имеют особенности при сборке).

>Это вскидку легко продолжить - оконные менеджеры,

нет там скриптов.

программы по умолчанию,

тоже нет. Файл положил в миме-базу и готово

плагины к программам,

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

взаимозависимые демоны-службы-сервисы...

нету там скриптов.

В гноме еще скрипты используют типа вызов gconftool или dev-help и вызов ldconfig.

>нет там скриптов.

В Debian есть, например. как минимум update-alternatives вызываются для линка x-window-manager в /etc/alternatives. Соответсвенно, нужны скрипты postinst и prerm. Для IceWM так.

>Это в идеально-сферическом случае и строго прямых руках писавшего спеку. А ставя где-то подобраный пакет на это можно только надеяться )

так всегда

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

так нужно.

Смотря что понимать под «нужны».

а вот так и понимать - не нужен.

Вон, например, вбокс после установки компилит ядрен модуль

зря. не нужно этого делать.

и создает группу вбоксюзеров.

а вот это то самое минимальное зло.

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

не может.

>> Вон, например, вбокс после установки компилит ядрен модуль

зря. не нужно этого делать.

А как нужно?

>А как нужно?

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

Или что на момент установки вбокса будет отсутствовать соответсвующий kernel-devel, gcc или загружено не то ядро?

тогда зачем все это, если в любой _подходящий_ момент можно сказать service vbox build и он все сделает?

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

Вообще-то нет, не логично. Без ядра VBox не работает, так что это обычная жесткая зависимость.

Или что на момент установки вбокса будет отсутствовать соответсвующий kernel-devel, gcc или загружено не то ядро?

Есть специалный типа зависимостей для этого, Predepends, кажется.тогда

зачем все это, если в любой _подходящий_ момент можно сказать service vbox build и он все сделает?

Затем, чтобы после инсталляции пакета он был готов к работе.

>Вообще-то нет, не логично. Без ядра VBox не работает, так что это обычная жесткая зависимость.

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

А что если к этому рабочему ядру вообще уже нет kernel-devel? Все, приехали, виртуалбокс уже не поставить?

Есть специалный типа зависимостей для этого, Predepends, кажется.тогда

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

Затем, чтобы после инсталляции пакета он был готов к работе.

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

Добавлю к ответу Зубка.

>> программы по умолчанию,
> Файл положил в миме-базу и готово

Какой файл? Если мы ассоциируем с одним и тем же типом более одной программы?

>>плагины к программам,

> нету там скриптов. просто сошка ложится в каталог программы

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

>> взаимозависимые демоны-службы-сервисы...

> нету там скриптов.

И при установке апача при живом лайти/нгниксе/вотэвер, апач по дефолту будет пытаться схватить 80-ый порт?

При установке еще одного ?dm никто не спросит, что использовать по дефолту?

> А что если к этому рабочему ядру вообще уже нет kernel-devel? Все, приехали, виртуалбокс уже не поставить?

Да. Потому что поставленный VBox будет неработоспособен, если kernel-devel утрачен.

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

Свои фантазии оставь при себе.

Затем, чтобы после инсталляции пакета он был готов к работе.

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

И к чему ты это сказал? При обновлении ядра пакет потеряет работоспособность в любом случае, строится модуль в pre/post-скрипте, или после инсталляции пакета.

Да и вообще, вопрос был «как делать правильно». Насколько я понял, твой ответ звучит так: «поставить VBox, который не будет запускаться до момента, когда будет выполнена команда service vbox build»?

> При установке еще одного ?dm никто не спросит, что использовать по дефолту?

Иисталляционные скрипты RPM не предназначены для интерактивной работы. Unattended installation, все дела.

>Да. Потому что поставленный VBox будет неработоспособен, если kernel-devel утрачен.

kernel-devel может быть позже найден или поставлен с новым ядром.

Свои фантазии оставь при себе.

Да какие там фантазии. Поставил вбокс - получил ошибку.

И к чему ты это сказал?

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

А гемора юзер уже поимел. Ибо он, оказывается, виртуалбокс даже поставить без кернел-девела не сможет. Молодца, пакажер! Рассово верный альтовый подход...

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

Или перезагрузился? Но опс, модули в скрипте не собираются с новым ядром! А со старым ядром все работало бы. И чего, жирный фэйл во весь экран, чтоб сука вернулся в старое ядро и оттуда ставил виртуалбокс? удаление виртуалбокс или вообще rm -rf / неудачнику?

При обновлении ядра пакет потеряет работоспособность в любом случае, строится модуль в pre/post-скрипте, или после инсталляции пакета.

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

Да и вообще, вопрос был «как делать правильно». Насколько я понял, твой ответ звучит так: «поставить VBox, который не будет запускаться до момента, когда будет выполнена команда service vbox build»?

да. Безбажно поставить вбокс. Эта процедура должна работать как совковая лопата.

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

вообще-то ядер может быть несколько

Вообще-то, VirtualBox использует DKMS. Другое дело, что DKMS у него в зависимостях не прописан (хотел бы я знать, почему)

>Какой файл? Если мы ассоциируем с одним и тем же типом более одной программы?

мимешный. Сколько программ проассоциировали, столько и должно быть в менющки «открыть с программой ...». Выбор шлавной программы - выбор юзера и он его делает в гуе.

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

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

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

И при установке апача при живом лайти/нгниксе/вотэвер, апач по дефолту будет пытаться схватить 80-ый порт?

а что, апач должен автоматом стартовать после установки? Нет. Установил и лежит. Сконфигурил - запускай.

При установке еще одного ?dm никто не спросит, что использовать по дефолту?

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

>Вообще-то, VirtualBox использует DKMS. Другое дело, что DKMS у него в зависимостях не прописан (хотел бы я знать, почему)

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

>>Да. Потому что поставленный VBox будет неработоспособен, если kernel-devel утрачен.

kernel-devel может быть позже найден или поставлен с новым ядром.

Тогда же может быть поставлен и VBox.

Свои фантазии оставь при себе.

Да какие там фантазии.

Про «половину пакетов».

Поставил вбокс - получил ошибку.

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

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

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

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

Ладно, спор бессмысленный. Удачи тебе в обходе систем управления пакетами.

> Ну логично — системы, ориентированные на установку из сорцов, имеют простую и понятную систему для этого.

Пацаны, не делайте мне смешно. Я в своё время на базе bsdmake одну прикладную системку сборки настряпал, должен вам доложить, там внутри BSD'шных .mk'шек такие перлы встречались, что ого-го :) В итоге пришлось и bsdmake подхачить, и фряшного набора .mk'шек отказаться :)

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

Ни в коем разе. RPM'ные postinstall скрипты не предназначены для выполнения сложных задач. Уже хотя бы потому, что ошибка на этом этапе приводит к прерыванию операции установки. Если хочется операций, которые бы выполнились после окончания установочной транзакции - следует воспользоваться механизмом посттранзакционных скриптов (те, которые подобно dpkg-reconfigure выполняются после окончания всей транзакции). Правда, я давно уже не разглядывал rpm-дистрибутивы, отличные от AltLinux, поэтому не уверен, везде ли внедрён этот механизм (в Альте он появился сравнительно недавно).

> Вообще-то нет, не логично. Без ядра VBox не работает, так что это обычная жесткая зависимость.

Строго говоря, всё плохо. Для случая чистой установки, да, RPM, _скорее всего_ , в данном случае проведёт инсталляцию пакета ядра раньше, чем пакета VirtualBox. Но если у вас не чистая инсталляция, а апгрейд (ну, например, апгрейд того же ядра), то здесь порядок определяется звёздами, а, часто, и _метапакетным_ менеджером, - точно помню, как нам приходилось обруливать баги установки, возникающие только под vzyum'ом.

В общем, нельзя гарантировать, что, если у пакета A стоит в зависимостях пакет B (даже в PreReq!), то в %postinstall A можно делать что-либо, привязывающее A к конкретной версии B.

> Unattended installation, все дела.

Но рыбки, честно, иногда очень хочется. Впрочем, к чему приводит дебиановская рыбка, я выше уже описывал :)

>> Это в идеально-сферическом случае и строго прямых руках писавшего спеку. А ставя где-то подобраный пакет на это можно только надеяться )

так всегда

Всегда что? Спек написан идеально, с использованием исключительно переменных для всех путей? )

так нужно.

Тоже не понял. Конечно так нужно, писать спеку максимально портабельно. Но реальность-то другое дело.

зря. не нужно этого делать.

Об этом тут уже подискутировали, имхо, единственный минус в том, что невыполнение этой операции может оборвать и установку. В остальном — если в 85% случаев вбокс будет запущен если не сразу, то на этом же ядре и т.п., этого, думаю, достаточно. А если нет — в лишней перекомпиляции ничего страшного, сами говорите ;)

не может

Значит для вас не может. А кому поставить, и чтобы оно работало с минимумом доп. телодвижений (обычные десктопные задачи, никакой не сервак) — там может. Это даже в случае если юзер отлично знает и как всё, что нужно руками сделать. А если не знает, заставлять его разбираться и докручивать установку >1000 пакетов стандартной системы — это, имхо, достаточно жестоко ;)

> Пацаны, не делайте мне смешно. Я в своё время на базе bsdmake одну прикладную системку сборки настряпал, должен вам доложить, там внутри BSD'шных .mk'шек такие перлы встречались, что ого-го :) В итоге пришлось и bsdmake подхачить, и фряшного набора .mk'шек отказаться :)

Смотря с чем сравнивать же ;) Там было емнип собрать для себя софтину pkgbuild'ом, или осиливать для этого сборку rpm, при одинаковом качестве, в смысле количестве потенциальных проблем.

> Правда, я давно уже не разглядывал rpm-дистрибутивы, отличные от AltLinux, поэтому не уверен, везде ли внедрён этот механизм (в Альте он появился сравнительно недавно).

Не оно? http://rpm.org/api/4.4.2.2/triggers.html

>Всегда что? Спек написан идеально, с использованием исключительно переменных для всех путей? )

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

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

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

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

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

В остальном — если в 85% случаев вбокс будет запущен если не сразу, то на этом же ядре и т.п., этого, думаю, достаточно. А если нет — в лишней перекомпиляции ничего страшного, сами говорите ;)

собственно, все.

> Использовать заранее определенные в рпм префиксы просто и очевидно, поэтому обычно и делается.

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

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

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

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

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

написать он их действительно безбажно не смог

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

> http://rpm.org/api/4.4.2.2/triggers.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

potentially_unsafe_command || :
potentially_unsafe_command2 || :
exit 0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

> А компиляция модуля - операция ненадежная и неоднократная и потому ей в скрипте установки делать нечего.

Если у меня ровно тот дистр, под который собран пакет, и я в нем руками сильно не ковыряюсь — в каком месте она ненадежная? Тут тогда просто желание с высокой вероятностью избавить пользователя от лишних движений. И опять же, насчет минусов — ну сделать так, чтобы ошибка компиляции не прерывала установку (хз, может там так и есть), и где они?

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

Ок, где и чего может быть порча? )

А у неё еще и спек есть?

Есть. Раз есть .rpm'ка (см. ниже), то есть и .src.rpm'ка, и спек. Но они где-то в недрах Sun'а, поэтому так просто не пофиксить

$ rpm -qi VirtualBox
Name        : VirtualBox                   Relocations: (not relocatable)
Version     : 3.0.12_54655_fedora12             Vendor: Sun Microsystems, Inc.
Release     : 1                             Build Date: Втр 17 Ноя 2009 10:31:46
Install Date: Чтв 19 Ноя 2009 15:32:02      Build Host: tinderlin.germany.sun.com
Group       : Applications/System           Source RPM: VirtualBox-3.0.12_54655_fedora12-1.src.rpm
Size        : 86213808                         License: VirtualBox Personal Use and Evaluation License (PUEL)
Signature   : DSA/SHA1, Втр 17 Ноя 2009 12:33:11, Key ID dcf9f87b6dfbcbae
URL         : http://www.virtualbox.org/
Summary     : Powerful PC virtualization solution
Description :
VirtualBox is a powerful PC virtualization solution allowing
you to run a wide range of PC operating systems on your Linux
system. This includes Windows, Linux, FreeBSD, DOS, OpenBSD
and others. VirtualBox comes with a broad feature set and
excellent performance, making it the premier virtualization
software solution on the market.

>Если у меня ровно тот дистр, под который собран пакет, и я в нем руками сильно не ковыряюсь — в каком месте она ненадежная?

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

И опять же, насчет минусов — ну сделать так, чтобы ошибка компиляции не прерывала установку (хз, может там так и есть), и где они?

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

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

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

А потом ругаются, что у них вайн молча сам стартует ) Да даже и апач.. мало ли.

> Есть. Раз есть .rpm'ка (см. ниже), то есть и .src.rpm'ка, и спек. Но они где-то в недрах Sun'а, поэтому так просто не пофиксить

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

> В рамках дистра можно сделать dkms-пакет и поставить зависимость на него. В этом пакете можно и модулечки положить пресобраные и патчики под ядрушки т.д.

Понятно что можно. Я спрашиваю в каком месте обсуждаемое решение ненадежно, при корректно обновляемом пакетнике.

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

«— У меня вбокс не работает. — Выполните в консоли VirtualBox, что пишет? — блабла, чтобы починить, выполните то-то. — Вот и выполните что пишет»

Это вот оно сложно? ;) Ну ладно, это в вбоксе так хорошо, в среднем случае будет «— пишет это. — Выполните то-то». Но где сложность-то?

Да и то, это вы всё про самый сложный случай, удаленную поддержку. А если есть только локальный админ, пусть даже «локалхоста», или просто юзер, то им это всё к чему?

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

В качестве мегакостыльного, но в принципе возможного решения «на месте» можно изобрести пустой RPM-пакет, тянущий по зависимостям и VirtualBox, и dkms. Будь у меня необходимость поддерживать инсталляцию не-OpenSource-ной версии VirtualBox более чем на одном хосте, я бы как-то так и сделал

> Пацаны, не делайте мне смешно. Я в своё время на базе bsdmake одну прикладную системку сборки настряпал, должен вам доложить, там внутри BSD'шных .mk'шек такие перлы встречались, что ого-го :) В итоге пришлось и bsdmake подхачить, и фряшного набора .mk'шек отказаться :)

Просто ты как не осиливал BSD make так и не осиливаешь. Он как-то не укладывается в твою парадигму «как должно быть». Хотя по сути это такой же макроязык как и configure.

> В качестве мегакостыльного, но в принципе возможного решения "на месте" можно изобрести пустой RPM-пакет, тянущий по зависимостям и VirtualBox, и dkms.

* выдыхая воздух и потуже затягивая пояс*

А что, в рпм-системах до сих пор нет виртуальных пакетов?

есть

А что, в рпм-системах до сих пор нет виртуальных пакетов?

AFAIU, я именно виртуальный пакет и описал

> «— У меня вбокс не работает. — Выполните в консоли VirtualBox, что пишет? — блабла, чтобы починить, выполните то-то. — Вот и выполните что пишет»

Это вот оно сложно? ;) Ну ладно, это в вбоксе так хорошо, в среднем случае будет «— пишет это. — Выполните то-то». Но где сложность-то?

Сложность в деньгах. На предыдущей работе product manager как-то обмолвился, что один голосовой звонок в саппорт - это примерно стоимость месячной подписки среднего клиента. Такая вот задница.

> В качестве мегакостыльного, но в принципе возможного решения «на месте» можно изобрести пустой RPM-пакет, тянущий по зависимостям и VirtualBox, и dkms.

А в чем смысл отдельного пакета? Воткнуть dkms так, и настроить на пересборку модуля вбокса при обновлении ядра, и всё, не?

А в чем смысл отдельного пакета?

В том, чтобы потом случайно не удалить dkms как «никому не нужный». Собственно, все мои эмоции по этому поводу от того, что некоторое время назад так и удалил (и думать забыл), а потом удивлялся — «а что-й-то у меня VirtualBox не запускается» (между сносом dkms'а и попыткой запуска Box'а успело выйти обновление к ядру)? Хорошо, что это было на домашнем компе, а не в продакшне каком-нибудь :)

> я именно виртуальный пакет и описал

Ты описал его как "пустой RPM-пакет", что подразумевает его существование в качестве файловой единицы, в отличие от.

> Сложность в деньгах. На предыдущей работе product manager как-то обмолвился, что один голосовой звонок в саппорт - это примерно стоимость месячной подписки среднего клиента. Такая вот задница.

Ах ё, так вот оно что. А мы тут уже n-ю страницу о технических преимуществах и недостатках вариантов сборки, как правильно, и как неправильно. А тут, оказывается, только жадность конкретного саппорта ;) При том, что в пользующейся организации своих спецов, получается, ноль, раз не могут даже вывод попытки запуска вбокса в консоли посмотреть.

Тогда мои ей сочувствия, вопрос закрыт )

В таком случае как «никому не нужный» ты удалишь этот пустой пакет, а за ним и dkms ;) Склероз найдет дорожку )

> И опять же, насчет минусов — ну сделать так, чтобы ошибка компиляции не прерывала установку (хз, может там так и есть), и где они?

За это надо бить по рукам. Это замалчивание проблемы, которая выстрелит позднее и гораздо больнее(с учетом времени потраченного на поиск проблемы). Правильным будет прервать установку как можно раньше(в идеале на стадии pre-*) и вернуть систему в прежднее состояние.

>Понятно что можно. Я спрашиваю в каком месте обсуждаемое решение ненадежно, при корректно обновляемом пакетнике.

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

— У меня вбокс не работает

ошибки будут другие. «у меня все похерилось» почему?

А потому что в простыночном скрипте допустили опечатку и пошло rm -rf /

Ты описал его как «пустой RPM-пакет», что подразумевает его существование в качестве файловой единицы, в отличие от

Каюсь, был терминологически некорректен. Вирт. пакеты в RPM есть. В качестве примера можно привести wine.src.rpm из Fedora — при сборке из него получается не wine.i686.rpm, а wine-core, wine-desktop, wine-common и еще куча пакетов wine-foobar. Кстати, кто-то выше по топику спрашивал, как из одного SRPM получить два и более RPM — посмторите wine в Fedora

> За это надо бить по рукам.

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

В таком случае как «никому не нужный» ты удалишь этот пустой пакет, а за ним и dkms ;)

Не-а. Я тогда «сказал» что-то вроде yum remove kernel-devel, посмотрел, что хочет удалиться вслед за ним по зависимостям, увидел dkms, не увидел (что важно) ничего, завязанного на dkms, и ничтоже сумняшеся подтвердил удаление. А так бы увидел помимо dkms'а и этот «ненужный» пакет, и вирт. бокс :)

> нужно ставить дополнительные пакеты, которые, собственно, при установке не нужны

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

И когда похерилось из-за

потому что в простыночном скрипте допустили опечатку и пошло rm -rf /

то с таким же успехом rm -rf / вобъешь или усталый ты в консоль, или девелопер софтины в исходник по ошибке. Так что конкретно к скриптам цепляться нечего, не выкидывать же эту возможность из стандарта из-за того, что туда можно rm вписать.

А при штатном функционировании, без выстрелов себе в ногу, это уже вообще не минус.

Ясно. Но все равно, похоже, можно проще:

$ yum info yum-plugin-protect-packages
Name       : yum-plugin-protect-packages
Arch       : noarch
Version    : 1.1.23
Release    : 1.fc11
Size       : 12 k
Repo       : updates
Summary    : Yum plugin to prevents Yum from removing itself and other protected packages
URL        : http://yum.baseurl.org/download/yum-utils/
License    : GPLv2+
Description: this plugin prevents Yum from removing itself and other protected packages.
           : By default, yum is the only package protected, but by extension this
           : automatically protects everything on which yum depends (rpm, python, glibc,
           : and so on).Therefore, the plugin functions well even without
           : compiling careful lists of all important packages.

или

Name       : yum-plugin-post-transaction-actions
Arch       : noarch                             
Version    : 1.1.23                             
Release    : 1.fc11                             
Size       : 13 k                               
Repo       : updates                            
Summary    : Yum plugin to run arbitrary commands when certain pkgs are acted on
URL        : http://yum.baseurl.org/download/yum-utils/
License    : GPLv2+
Description: This plugin allows the user to run arbitrary actions immediately following a
           : transaction when specified packages are changed.

>Тоже в первый раз прозвучало. Какие, dkms? А у меня из-за вбокса вообще ничего не стоит, и как-то ничего, даже не напрягает.

kernel-devel, gcc

то с таким же успехом rm -rf / вобъешь или усталый ты в консоль, или девелопер софтины в исходник по ошибке.

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

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

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

Во-первых, сначала обсуждали прерывание установки пакета при сбое скрипта как минус.

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

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

yum-plugin-protect-packages

yum-plugin-post-transaction-actions

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

> kernel-devel, gcc

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверное, не совсем аналог, это как я понимаю предназначено для использования на месте установки пакетов, а не при их создании. Но насчет posttrans — вот похоже ровно оно, нет? http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

«%pretrans and %posttrans are available in rpm 4.4 and later»

Можно ли осуществлять автоматическую доустановку требуемых пакетов на этом этапе?

Как понимаю, можно много чего, но вряд ли мэйнтейнеру:

$ cat /usr/share/doc/yum-plugin-post-transaction-actions-1.1.23/sample.action
#action_key:transaction_state:command                                                               
# action_key can be: pkgglob, /path/to/file (wildcards allowed)                                     
# transaction_state can be: install,update,remove,any                                               
# command can be: any shell command                                                                 
#  the following variables are allowed to be passed to any command:                                 
#   $name - package name                                                                            
#   $arch - package arch                                                                            
#   $ver - package version                                                                          
#   $rel - package release                                                                          
#   $epoch - package epoch                                                                          
#   $repoid - package repository id                                                                 
#   $state - text string of state of the package in the transaction set                             
#                                                                                                   
# file matches cannot be used with removes b/c we don't have the info available                     

*:install:touch /tmp/$name-installed
zsh:remove:touch /tmp/zsh-removed   
zsh:install:touch /tmp/zsh-installed-also
/bin/z*h:install:touch /tmp/bin-zsh-installed
z*h:any:touch /tmp/bin-zsh-any

И не совсем понял, когда это может понадобиться, вместо метапакета или зависимостей.

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

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

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

Я про это и говорю. Просто чел предлагал МОЛЧА ставиться в систему и если повезет юзер заметит проблему, глядя в консоль.

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

Как раз 'ports' со своей задачей справляется. Сливает пакетный менеджер(Внутрь лучше вообще не заглядывать). Проблема в том, что при непонимании как правильно писать на BSD make Makefile-ы превращаются в набор костылей.

> Проблема в том, что при непонимании как правильно писать на BSD make

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

Да, диагностика нужна. И, судя по запросам пользователей, нужна кнопка — «откатить всё взад, ну её нахрен вашу новую версию!»

Ну и, если уж зашла речь про autotools с компанией, то в классических портах мешает отсутствие промежуточных артефактов, a-la ./configure, Makefile.in и т.п. Отлаживать сколько-нибудь сложный код, глядя в выхлоп make (хоть и в debug-режиме) неприятно. Хотя и возможно.

Факт работоспособности портов не оспариваю. В исходники пакетного менеджера смотрел, рыдал, смеялся, много думал, просил дать другую задачу... (: Смотрел и в содержимое ports core .mk-шек. Вот там и есть набор костылей, увы. AlexM не даст соврать (: