|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 02 Jan 2003 13:36:52
To : Aleksey Barabanov
Subject : Зависимости пакетов в дистрибутиве Linux.
--------------------------------------------------------------------------------
Hi, Aleksey!
>>>>> "AB" == Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
AB> Что бы более не было всяких передергиваний напишу одним абзацем, более
AB> не буду повторять и отвечать на сопутствующий бред не буду тоже :
AB> 1.Установка в одну транзакцию ВСЕГО дистрибутива невозможна и тем
AB> более это невозможно если требуется манипулировать отдельными
AB> пакетами. Следовательно это имеет смысл только для группы пакетов.
так и есть, группы пакетов. Обычно циклические зависимости "затрагивают"
два пакета, очень редко три (пример из трех пакетов я так сходу даже не
вспомню).
AB> 2.Установка в одну транзакцию группы пакетов создает подмножество
AB> зависимостей которые фактически внутри более не анализируются.
"более не анализируются" еще нужно доказать. Все анализируется.
Транзакция - оперция, которая переводит базу данных о пакетах из одного
непротиворечивого состояния, в другое. Анализируются все зависимости
которые будут _после_ завершения транзакции.
AB> Следовательно более не проверяются ошибки в зависимостях внутри этой
AB> группы, а значит они имеют тенденцию наростать.
ниоткуда оно не следует. И никакой тенденции нет.
AB> 3.Определить группу пакетов, входящих в одну неразделюемую
AB> транзакционную установку, можно только путем проб и ошибок,
странно, может просто построить дерево зависимостей?
Я даже неходил покет rpmgraph, который суть набор скриптов, дергающих из
rpmdb зависимости, и потом через graphviz рисует дерево.
Теорию графов знаем? Выделить циклы в построеном графе - задачка из
лабораторной по этому курсу.
AB> а фактически такая группа формируется постепенно путем наростания
AB> взаимных зависимостей внутри группы.
опять-же, голословные утверждения. нет, я не буду опровергать, мне это
ненужно. Я расскажу ПУТИ, следуя которыми, каждый КОМУ HУЖHО это
опровергнуть, сможет найти правильный ответ.
AB> Т.е. такая группа пакетов не имеет эквивалентного тага в rpm, а
AB> является продуктом творчества разработчиков, которые пользуются rpm
AB> как инструментом.
Группа, которая записана в tag'е, она для человека. Классификация пакета.
AB> Другими словами, rpm как инструмент, внутри содержит неразрешимую
AB> проблему.
...которая является проблемой по всей видимости только для Алексея ;)))
AB> 4.Все инструменты управления пакетами, которые базируются на rpm,
AB> например yast, для объединения пакетов в группы, требующие
AB> транзакционной установки, вынуждены создавать собственные описания
AB> таких групп.
разумеется. Хотите чтоб такую функциональность внесли на уровень rpm?
Hапишите свои претензии в списки рассыки rpm'а. Там, по крайней мере
ОТВЕЧАЮТ люди, которые это могут релаьно сделать.
AB> Hо в базу rpm эта информация не заносится.
зачем хранить то, что можно расчитать? Для экономии времени расчета?
Есть ли смысл тратить дорогой ресурс "время разработчика", чтоб экономить
недорогой ресурс "время процессора"?
Я думаю что нет смысла. Темболее что разработчики не бездельничают.
AB> Именно это затрудняет ручное использование rpm в дистрибутивах с
AB> такими менеджерами.
затрудняет КОГО? Алексея?
AB> И это же значит, что добавление "мозгов" rpm за счет внешнего
AB> менеджера является полумерой, и ничего по-сути не решает.
а что нужно решать-то? Еще инетерсно, _зачем_ оно нужно, какой такой
качественно положительный результат это решение принесет...
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
