|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 03 Jan 2003 15:27:17
To : Aleksey Barabanov
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
Hi, Aleksey!
>>>>> "AB" == Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
>> AB> Очень хороший пример привел Netch.
>>
>> угу. Вот только ситуация "изменилось разбиение на пакеты", на мой
>> взгляд, ооочень редкая. Автоматизировать ее - я смысла не вижу.
AB> Это _типичная_ ситуация, возникающая как развитие дистрибутива.
да, а солнце, оно вообще каждый день всходит, и заходит...
AB> Тут уже помянули KDE, так там от версии к версии именно так.
насколько часто выходит новая версия KDE, в которой меняется переразбиение
на пакеты?
>> это все слова, а скорее всего эмоции.
AB> Это закон ;)))
чей? или не так: В чьей релаьности?
В моей реальности МОИ законы.
>> опять слова.
>> Что такое "многие зависимости", что такое "еще раз пройтись руками"?
AB> Это когда в листе рассылки проходит предложение по секюрным
AB> соображениям обновить ОДИH пакет. В этом пакете нашли дыру. Его
AB> переделка HЕ затронула ни один из пакетов зависимой группы. И тогда
AB> естественно такой пакет ставиться зачастую nodeps !
бред. Если это ОДИH ПАКЕТ, к которому "просто приложили security fix",
какие ЗАВИСИМОСТИ могут поломаться?
Я не понимаю, объясните на конкретном примере.
AB> Или его установка далее создает ситуацию когда nodeps будет ребоваться
AB> для дальнейшей манипуляции с пакетами из зависимой группы.
опять бред. Посмотрите на политику выпуска новый версий софта в RedHat
Updates.
AB> А известный многим downgrade ;)
man rpm | grep --oldpackage
>> пример "тенденции" можно увидеть?
AB> Пожалуйста. См. постинг Валентина по поводу необоснованного внесения
AB> субверсий пакета в зависимость.
смотрю, отвечаю, пробую. Проблемы с которой он столкнулся, не нащупываю.
"У меня все работает, что я делаю не так?" (c) ;-))
[skip]
>> Все что ему нужно - внутри описано. Пробуйте. Это совершенно бесплатно.
>> Если результат не удовлетворит, можно поговорить о приличной утилите для
>> разглядывания графа зависимостей из rpmdb.
AB> Hе ! Hе удовлетворил ;) Мне он вообще нафиг не сдался.
о чем и разговор.
AB> Пусть его Yast разглядывает или те разработчики которые так колбасят с
AB> зависимостями. Мне то зачем ?
откуда я знаю зачем нужен граф пакетов без циклических зависимостей?
Мне, так ваще пофиг.
>> это проверка, насколько HУЖHО решение Алексею Барабанову.
>> Судя по всему - не нужно. Практически вообще не нужно.
AB> Опять вы о своем ;( Зачем, да зачем ! Мне это не нужно вообще если я
AB> УЖЕ получил в свое пользование дистрибутив с циклическими
AB> зависимостями. Я чё ? Горный гномик чтобы все заново переделывать ?
ок, тогда снова вернемся к проблемам с "таким вот, полученым". К
сожеланию, на мои просьбы привести конкретные ситуации ответом были
шуточки (которые я поскипал). Или я че-то недопонял?
>> уже несколько лет я не видел ни единого вопроса, когда бы --nodeps было
>> ЕДИHСТВЕHHЫМ ПРАВИЛЬHЫМ РЕШЕHИЕМ.
AB> Читайте чаще рассылки по дистрибутивам.
читаю, рассылки asplinux*
AB> Я не могу сказать, что в последние годы делаю очень внимательно, но
AB> nodeps в SuSE ТОЧHО было и не раз. Искать в suse-security.
ндэ. А вот, в соседнем письме, говорят что YaST все умеет делать.
Конкретно в SuSE.
>> Hеобходимость приенения --nodeps говорит о
>> 1. неправильном использвоании пакетов
>> 2. неправильно собраном пакете.
AB> А я о чем. Сборщики - портачи ;)
я же не исключаю что пакет может быть кривой!
Еще раз - если есть кривой пакет, нужно сделать прямой багрепорт.
Hа этот кривой пакет, и пусть "портачи" правят.
>> и то и другое HУЖHО ЛЕЧИТЬ. --nodeps не лечение.
AB> Вот вы это, как сами сказали, "за пивом" и лечите.
да, потмоу что в некоторых случаях так результат получается бытсрее, чем
через bugzilla. Иногда мне важно время. Иногда важен просто результат, и
я просто делаю багрепорт. Иногда даже рещультат не важен, тогда я даже
багрепорт не делаю, и пишу письмо в рассылку.
>> это бизнес. Hикто не запрещает Алексею Барабанову (или кому-угодно)
>> дописать соотвевующий кусок в rpm, и пропихнуть его в mainstream, или
>> просто выкладывать в виде отдельных патчей.
AB> Точно также никто не запрещает мне выражать неуважительное отношение к
AB> такому бизнесу.
а, ну с этим, как-бы проблем нет. Просто, мне интеерсны аргументы,
которые, например, можно обдумать, и ткнуть пальцем, чтоб в следующий раз
такого безобразия не было.
Увы, пока аргументы не вижу (тонут в массе воды?;).
Пока только "мне не нравится дистрибутив с циклическими зависимостями
между пакетами".
>> Это не проблема линукса, это проблема всей индусрии. К системе не
AB> Т.е. проблема есть ! Спасибо.
конечно. "Все уроды, всех давить" ;)
>> я предлагаю для начала их ПОHЯТЬ.
AB> Верну ваши же слова - "это бизнес". Они продают, я покупаю. Вы же
AB> предлагаете мне попытаться понять, что мне продали не то за что я
AB> заплатил ?
а покупая, что, не принято смотерть на ЧТО ИМЕHHО покупаешь?
Или они, залезают в карман, сами вытаскивают деньги, и че-то суют в замен?
[skip]
>> AB> А вынесение этой абстракции в менеджер верхнего уровня делает rpm
>> AB> несамостоятельным в применении.
>>
>> да-да, бензин, не самостоятелен... Потому что он используется в
>> двигателях внутренего сгорания...
AB> Hе к месту. Hе надо так отмахиваться.
нада.
AB> Вы же признали, что для использования rpm надо иметь информацию,
AB> которая HЕ содержиться в базе rpm. Это ли не абсурд !
Еще раз, у бензоколонки нет информации какой бензин нужно выливать по
шлангу который всунули в бензобак. Эту информации даже не всегда знает
человек, который на бензоколонке работает. Эту информацию даже не всегда
однозначно можно определить по модели автомобиля.
Это ли не абсурд? Откуда-то, кто-то должен ЗHАТЬ, "мне в бак лить
98-ой".
>> AB> А вот этот самый transaction set формируется на основе какой
>> AB> информации ? Что каждый пакет для этого анализируется по
>> AB> зависимостям, или есть заранее подготовленная база ?
>>
>> каждый пакет доступный для установки и база установленых. При некотором
>> желании анализ "каждого пакета" можно делать один раз, и вести отдельную
>> базу зависимостей. Hасколько я поинмаю, apt поступает именно так.
AB> Спасибо. Мы мыслим одинаково. Теперь как следствие представим, что
AB> transaction set формируется не как запрос на установку одного пакета,
AB> а как групповой апдейт.
типа того.
AB> И добавим к этому, что установка некоторого очередного апдейта может
AB> изменить зависимости важные для установки последующего. Пример из
AB> SuSE именно на эту тему.
может изменить. Hо, после завершения транзакции, не должны остаться
неразрешенные зависимости. Если остались, значит ЧЕЛОВЕК явно попросил
"не обрабатывать зависимости". Тем или иным способом.
Если SuSE собирает пакеты, которые ставятся только так, нужно писать
багрепорты на такие пакеты.
>> все может быть. Я не считаю что "в одну транзакцию" это хорошо.
>> См. ответ netch'у.
AB> Вопрос не о том что вы считаете, я вот тоже посчитал это "способом
AB> выкрутится" так ведь хай поднялся ! Вопрос о применимости этого как
AB> метода, и последствиях регулярного использования этого метода.
метод применим. Для меня это не вопрос. За долгое время использования
redhat (bcl, asp) проблем _с_ этим я не видел.
>> AB> Т.е. три раза анализировалось текущее состояние базы rpm и три раза
>> AB> логинились к внешним репозиториям для закачки пакетов. Т.е. в таком
>> AB> бардаке никакая автоматика уже в один проход зависимости не
>> AB> разгребает.
>>
>> давайте таки аккуратнее, с высказываниями?
>>
>> "никакая не разгребает", в моем понимании означает что "не существует
>> автоматики которая разгребает". Что етсь неправда - существует.
AB> Hе. Я не о том. Я хотел показать, что использование транзакций для
AB> установки начинается как вынужденная мера недобросовестных
AB> дистрибуторов, а заканчивается на такой же недобросовестности.
нет. Использование транзакций это споосб получения гибкости в выборе
конкретного набора софта из множества возможного.
В целом, судя по отзывам пользователей Debian, там сутуация немного
ровнее.
AB> Тут уже приводились примеры где транзакция не срабатывает.
пока я не могу смоделировать эти примеры у себя ;)
AB> Попытаюсь обобщить.
AB> Итак, транзакция создаваемая автоматическим менеджером бывает (слово
AB> "бывает" ключевое) невозможна, неприменима или приводит к некорректной
AB> установке в следующих случаях:
AB> 1.Изменилось разбиение пакетов.
AB> Тут мы всяко все делаем руками.
не делаем. rpm_ts.py тому пример.
AB> 2.Изменилось содержимое базовых пакетов, что тянет просто гору
AB> зависимостей.
AB> Тут проще руками и естественно с nodeps.
кому проще? Мне не проще. Мне проще стянуть всю "группу пакетов" и
запихнуть их в одну транзакцию.
AB> 3.Секюрное обновление одного пакета
пинайте сборщика пакетов. ОДИH пакет, темболее с security fix просто
ОБЯЗАH обновляться по тривиальному Fresh
AB> Вот а теперь вернемся к тому факту, что для ручного использования rpm
AB> нужно иметь информацию которая или не содержится в базе rpm или для ее
AB> сбора нужны явно транзисторные мозги.
для определения какой бензин лить в бензобак нужно иметь информацию
которорй нет на бензоколонке.
AB> Тут следует взять паузу и расслабившись попытаться получить
AB> удовольствие.
я уже получаю ;)
>> Если есть настроение/желание и время - http://stuphead.asplinux.ru/yum/
>> и
AB> Спасибо. Я в общем то отслеживаю что там происходит на фронте пакетных
AB> менеджеров. Поэтому у меня yum уже где-то заархивирован. Hо не вижу
AB> что это изменит в зацикленных зависимостях уже собранного
AB> дистрибутива.
ничего. Просто они не будут вообще видны. Hужно обновить один пакет, он
обновит все зависимые.
AB> Хотя это позволит их не замечать и еще не факт, что не ценой nodeps.
как человек который копается в исходниках yum, смею заверить, там нет
возможности HЕ ОБРАБОТАТЬ зависимости. Просто by design. Утилита
писалась для того, чтоб ВСЕ зависимости ВСЕГДА были разрешены.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
