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

А, в смысле платный факультатив по винде? Епт, сразу и не подумал.

Это да, это правильно и нужно. И опциональную сертификацию MCSA в конце. Даешь настоящих, востребованных технических специалистов на рынок труда!

> Да. Обычно более одного и получается.

В смысле? У меня вроде бы по дефолту один получался, под целевую систему, и всё.

> В смысле? У меня вроде бы по дефолту один получался, под целевую систему, и всё.

Это все твои руки....

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

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

> Это все твои руки....

Так мне только это и надо было :P

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

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

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

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

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

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

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

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

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

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

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

Почти RPM, я смотрю...

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

так всегда

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

так нужно.

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

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

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

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

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

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

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

не может.

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

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

А как нужно?

>А как нужно?

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

Или что на момент установки вбокса будет отсутствовать соответсвующий 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 будет выдвать ошибку при попытке его запуска.

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

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

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

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

> они чего, RPM придумали?

Ещё не совсем. Еще подпись осталось приделать/стандартизовать.

Надо будет теперь еще разок попробовать освоить сборку дебок...

Хых, было бы что умного. Проблема в том, что у них там _слишком много_ способов сборки дебок. Равно как и средств поддержки этой сборки. Хочешь - из SVN'а собирайся, хочешь - из GIT'а, и г-на Тэйлганнера почти наверняка есть чем порадовать. Короче, зоопарк - почище зоопарка в совокупности всех RPM-based сборочных песочниц.

> г-на Тэйлганнера

тов.

Короче, зоопарк - почище зоопарка в совокупности всех RPM-based сборочных песочниц.

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

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

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

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

Я до сих пор со ржанием вспоминаю, как в Этче во время установки апдейтов, выполненной в xterm'е, запустился reconfigure на X'ы, и вывел сообщение, что-де моя видеокарточка ему неизвестна, настроить X'ы по-нормальному он мне не может, а посему сейчас отконфигурирует всё для VESA. Свят-свят-свят! - сказал я и пристрелил процесс апгрейда, всё потом руками доконфигурял. Дело, напомню, происходило в полноценной X'овой сессии, причем, Этчевый инсталлятор вполне справился и с карточкой и с правильной настройкой режимов.

Ну а вот история буквально последних двух недель. Девочке из саппорта, сидящей на апдейченном Lenny, заменили монитор с простого на вайдскриновый. Она попросила админа «растянуть картинку». Тот, не долго думая, запустил reconfigure на X'у. Картинка, да, растянулась. Админ ушёл. Правда, заодно слетела ещё и переключалка клавиатуры, но обнаружила это хозяйка компа несколько позже, только когда попыталась начать собственно работать: клиентам отвечать, тикеты писать...

> тов.

Ok.

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

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

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

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

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

Привет make'у внутри. Вообще, городить сложные системы на базе make - это развлечение не для слабонервных.

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

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

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

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

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

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

> srpm конечно по-мощнее, эта штука позволяет пэкэджеру учесть, на каком дистрибутиве собирается пакет, если это имеет значение

Это имеет значение почти всегда. Но только встроенных в rpm'ный спек средств всё равно не хватает ни для чего сколько-нибудь серьёзного. На моей предыдущей работе для сборки подходящих для каждой из ~20 поддерживаемых систем (ну, все популярные RPM-дистрибутивы нескольких последних версий «обеих» архитектур, Debian, Ubuntu, FreeBSD) всё равно пришлось городить монстрика (опять-таки, на базе bsdmake), который бы из генерализованного описания набора пакетов создавал бы в полностью автоматическом режиме пакеты, пригодные для установки в каждом из дистрибутивов.

> Это потому что в rpm это имеет значение :}

А в .deb - не имеет? Ха! Ха-ха!

> Братцы, вон ALT уже в git всё хранит, а вы только до уровня src.rpm десятилетней давности добрались ;)

Они тоже хранят. Только у них сильно больше одной VCS поддерживается. См. выше про зоопарк.

> rpmfind.net

rpmforge.net

rpm.pbone.net

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

> ну, кошмар.

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

> и собирать их на других дистрибутивах тоже, где нет дебиан-специфичных утилит

Патчиков хотите наворовать? :)

> А вобще, использование АПТ в рпмных дистрибутивах как бы намекает...

Что намекает? apt, увы, уже не лучший метапакетный менеджер. А уж как он внутри написан - так свят-свят-свят... Лучше уж в ясте, чур меня! ковыряться, чем в этом высокотехнологичном...

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

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

> Кстати, вопрос знатокам srpm - из него можно генерить более одного пакета?

Так, как правило, и происходит. Причём, описание заметно более наглядное, чем в debian/:

http://www.sisyphus.ru/ru/srpm/Sisyphus/ConsoleKit

как пример

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

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

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

Что «ха»? Вы словами, словами.

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

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

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

Чем они так прибиты? Вот в своё время Krusader от убунту спокойно на дебиане заработал.

> Чем они так прибиты? Вот в своё время Krusader от убунту спокойно на дебиане заработал.

Блин. Я, если чО, в своё время плавно переехал с RedHat'а (наверное, это был RedHat-7.x) на мэндрейк, а оттуда на альтлинукс (или тогда это был ещё MandrakeRE?). Ни разу не запустив инсталлятора, всё строго через rpm -U, rpm -i и такую-то мать. Потом, к счастью для компа, у него сдох винт, а у меня нашлись более интересные занятия, чем насиловать rpm'ную базу.

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

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

>Но стоит коснуться чего-нибудь системно-зависимого

facepalm.svgz Это никак не зависит от менеджера пакетов. Ставить системно-зависимые пакеты от одной системы в другую это ССЗБ.

например eglibc )

> Ставить системно-зависимые пакеты от одной системы в другую это ССЗБ.

Ну, не так уж и ССЗБ ;) но, в общем, выше именно про это я и говорил. Только линукс не MacOSX, и нельзя сказать, что вот - это системное окружение и разлито Джоббсом и компанией, а вот это - прикладной софт. Поэтому «возможны нюансы».

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

последний форпост империи rpm пал :D