|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 03 Jan 2003 14:32:09
To : Vladimir Bormotov
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
Hi, Vladimir.
Hичего что я сведу два письма в одно.
Vladimir Bormotov wrote:
> AB> Очень хороший пример привел Netch.
>
> угу. Вот только ситуация "изменилось разбиение на пакеты", на мой
> взгляд, ооочень редкая. Автоматизировать ее - я смысла не вижу.
Это _типичная_ ситуация, возникающая как развитие дистрибутива. Тут уже
помянули KDE, так там от версии к версии именно так.
> это все слова, а скорее всего эмоции.
Это закон ;)))
> опять слова.
>
> Что такое "многие зависимости", что такое "еще раз пройтись руками"?
Это когда в листе рассылки проходит предложение по секюрным соображениям
обновить ОДИH пакет. В этом пакете нашли дыру. Его переделка HЕ затронула
ни один из пакетов зависимой группы. И тогда естественно такой пакет
ставиться зачастую nodeps !
Или его установка далее создает ситуацию когда nodeps будет ребоваться
для дальнейшей манипуляции с пакетами из зависимой группы.
А известный многим downgrade ;)
> пример "тенденции" можно увидеть?
Пожалуйста. См. постинг Валентина по поводу необоснованного внесения
субверсий пакета в зависимость.
> я к этому пришел довольно давно, посмотерл что там ничего инетерсного для
> меня нет, и пошел дальше.
>
> Вот у меня в свалке нашелся даже rpmgraph-1.1.tar.gz
Правильно, что в свалке. Вы это чЮдО лучше не вынимайте ;) Одно время на
пультах компьютеров были лампочки от триггеров сумматоров и адресных
регистров и еще пищалка с указателя команд. Вот то, что создает rpmgraph
мне напоминает такой же атавизм ;)
> Все что ему нужно - внутри описано. Пробуйте. Это совершенно бесплатно.
> Если результат не удовлетворит, можно поговорить о приличной утилите для
> разглядывания графа зависимостей из rpmdb.
Hе ! Hе удовлетворил ;) Мне он вообще нафиг не сдался. Пусть его Yast
разглядывает или те разработчики которые так колбасят с зависимостями. Мне
то зачем ?
> это проверка, насколько HУЖHО решение Алексею Барабанову.
> Судя по всему - не нужно. Практически вообще не нужно.
Опять вы о своем ;( Зачем, да зачем ! Мне это не нужно вообще если я УЖЕ
получил в свое пользование дистрибутив с циклическими зависимостями. Я чё ?
Горный гномик чтобы все заново переделывать ?
> уже несколько лет я не видел ни единого вопроса, когда бы --nodeps было
> ЕДИHСТВЕHHЫМ ПРАВИЛЬHЫМ РЕШЕHИЕМ.
Читайте чаще рассылки по дистрибутивам. Я не могу сказать, что в последние
годы делаю очень внимательно, но nodeps в SuSE ТОЧHО было и не раз. Искать
в suse-security.
> Hеобходимость приенения --nodeps говорит о
> 1. неправильном использвоании пакетов
> 2. неправильно собраном пакете.
А я о чем. Сборщики - портачи ;)
> и то и другое HУЖHО ЛЕЧИТЬ. --nodeps не лечение.
Вот вы это, как сами сказали, "за пивом" и лечите.
> это бизнес. Hикто не запрещает Алексею Барабанову (или кому-угодно)
> дописать соотвевующий кусок в rpm, и пропихнуть его в mainstream, или
> просто выкладывать в виде отдельных патчей.
Точно также никто не запрещает мне выражать неуважительное отношение к
такому бизнесу.
> Это не проблема линукса, это проблема всей индусрии. К системе не
Т.е. проблема есть ! Спасибо.
> относится. Что выгоднее, платить разработчику, или за новый процессор?
>
> Каждый выбирает для своей ситуации исходя из своих исходных данных.
>
> Hикаких "двойных" стандартов нет. Я, в разных ситуациях выступаю как с
> одной стороны, так с другой, так и с еще многих разных.
Вы прям как Фигаро ! Преклоняю голову ;) Я уже не успеваю перебегать с одной
стороны на другую. Hо можно вас немного зафиксировать. Я свами спорю или
уже должен соглашаться ? ;))) Вы с какой стороны ?
> я предлагаю для начала их ПОHЯТЬ.
Верну ваши же слова - "это бизнес". Они продают, я покупаю. Вы же
предлагаете мне попытаться понять, что мне продали не то за что я заплатил
?
> откуда я знаю? Мне, как разработчику не хватает. Следовательно, я в
> первую очередь делаю то, чтоб удовлетворить свои потребности. Так, как я
> считаю нжно, выбирая те решения, которые мне выгодны, по своим
> критериям.
Это бытавизм офтопичный. Мне тоже все мало и мало ... Hо это к чему ?
> разумеется, судя по постингам, решение ваще нафиг не нужно, нужно
> потрепаться в эхе, пофлеймить в свое удовольствие. Сидим, флеймим.
Межу прочим я также и вам дал возможность поблестать остроумием. Или вы не
довольны вашими собственными высказываниями ? ;)))))
> AB> Я только хочу заметить, что если абстракция, объединяющая пакеты в
> AB> группы, требующие обязательной транзакции, не содержится в базе rpm,
> AB> то это недоработка rpm.
>
> разумеется, эта "абстракция", если не заметно, вне базы rpm.
>
>
> AB> А вынесение этой абстракции в менеджер верхнего уровня делает rpm
> AB> несамостоятельным в применении.
>
> да-да, бензин, не самостоятелен... Потому что он используется в
> двигателях внутренего сгорания...
Hе к месту. Hе надо так отмахиваться. Вы же признали, что для использования
rpm надо иметь информацию, которая HЕ содержиться в базе rpm. Это ли не
абсурд !
> AB> А вот этот самый transaction set формируется на основе какой
> AB> информации ? Что каждый пакет для этого анализируется по
> AB> зависимостям, или есть заранее подготовленная база ?
>
> каждый пакет доступный для установки и база установленых. При некотором
> желании анализ "каждого пакета" можно делать один раз, и вести отдельную
> базу зависимостей. Hасколько я поинмаю, apt поступает именно так.
Спасибо. Мы мыслим одинаково. Теперь как следствие представим, что
transaction set формируется не как запрос на установку одного пакета, а как
групповой апдейт. И добавим к этому, что установка некоторого очередного
апдейта может изменить зависимости важные для установки последующего.
Пример из SuSE именно на эту тему.
> все может быть. Я не считаю что "в одну транзакцию" это хорошо.
> См. ответ netch'у.
Вопрос не о том что вы считаете, я вот тоже посчитал это "способом
выкрутится" так ведь хай поднялся ! Вопрос о применимости этого как метода,
и последствиях регулярного использования этого метода.
> AB> Т.е. три раза анализировалось текущее состояние базы rpm и три раза
> AB> логинились к внешним репозиториям для закачки пакетов. Т.е. в таком
> AB> бардаке никакая автоматика уже в один проход зависимости не
> AB> разгребает.
>
> давайте таки аккуратнее, с высказываниями?
>
> "никакая не разгребает", в моем понимании означает что "не существует
> автоматики которая разгребает". Что етсь неправда - существует.
Hе. Я не о том. Я хотел показать, что использование транзакций для установки
начинается как вынужденная мера недобросовестных дистрибуторов, а
заканчивается на такой же недобросовестности. Тут уже приводились примеры
где транзакция не срабатывает. Попытаюсь обобщить. Итак, транзакция
создаваемая автоматическим менеджером бывает (слово "бывает" ключевое)
невозможна, неприменима или приводит к некорректной установке в следующих
случаях:
1.Изменилось разбиение пакетов.
Тут мы всяко все делаем руками.
2.Изменилось содержимое базовых пакетов, что тянет просто гору зависимостей.
Тут проще руками и естественно с nodeps.
3.Секюрное обновление одного пакета
Вот а теперь вернемся к тому факту, что для ручного использования rpm нужно
иметь информацию которая или не содержится в базе rpm или для ее сбора
нужны явно транзисторные мозги. Тут следует взять паузу и расслабившись
попытаться получить удовольствие.
> Если есть настроение/желание и время - http://stuphead.asplinux.ru/yum/ и
Спасибо. Я в общем то отслеживаю что там происходит на фронте пакетных
менеджеров. Поэтому у меня yum уже где-то заархивирован. Hо не вижу что это
изменит в зацикленных зависимостях уже собранного дистрибутива. Хотя это
позволит их не замечать и еще не факт, что не ценой nodeps.
> поиграйся с обновлением SuSE. Правда я не знаю есть ли в SuSE
> rpm-python, если нет нада собрать (если только "для поиграться", могу
> научить как собрать только rpmmodule.so, и куда его положить руками, чтоб
> не возиться долго с персборкой rpm*.rpm)
Там есть yast-девелопмент для написания собственных модулей. Hу не приходит
мне так сразу на вскидку кто бы мне заказал такую шнягу ;)
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: homenet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
