|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 02 Jan 2003 14:14:09
To : Vladimir Bormotov
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
Vladimir Bormotov wrote:
> AB> 2.Установка в одну транзакцию группы пакетов создает подмножество
> AB> зависимостей которые фактически внутри более не анализируются.
>
> "более не анализируются" еще нужно доказать. Все анализируется.
> Транзакция - оперция, которая переводит базу данных о пакетах из одного
> непротиворечивого состояния, в другое. Анализируются все зависимости
> которые будут _после_ завершения транзакции.
Очень хороший пример привел Netch. "Более не анализируются" имеется ввиду,
что до попытки разбиения такой группы в ней могут возникать всякие
внутренние необоснованные усложнения. Внутри все уравновешено, но если
попытаться еще раз руками пройтись по зависимостям, то многое окажется
абсурдным. При этом автоматическая генерация зависимостей все строит как
надо.
> AB> Следовательно более не проверяются ошибки в зависимостях внутри этой
> AB> группы, а значит они имеют тенденцию наростать.
>
> ниоткуда оно не следует. И никакой тенденции нет.
Hет есть. Логика очень проста, если что-то не пополнять, то это однажды
непременно кончиться. Такова природа. Вопрос когда, это уж вторично. В
коммерческом смысле может и никогда.
> AB> 3.Определить группу пакетов, входящих в одну неразделюемую
> AB> транзакционную установку, можно только путем проб и ошибок,
>
> странно, может просто построить дерево зависимостей?
Странно, может просто это построить ? И тогда будут сразу видны циклические
связи.
> Я даже неходил покет rpmgraph, который суть набор скриптов, дергающих из
> rpmdb зависимости, и потом через graphviz рисует дерево.
>
> Теорию графов знаем? Выделить циклы в построеном графе - задачка из
> лабораторной по этому курсу.
О ! Я в вас не сомневался. Я только не хотел вас слишком подталкивать. Hо вы
и сами к этому пришли. Значит и у меня есть логика. Спасибо.
> AB> а фактически такая группа формируется постепенно путем наростания
> AB> взаимных зависимостей внутри группы.
>
> опять-же, голословные утверждения. нет, я не буду опровергать, мне это
> ненужно. Я расскажу ПУТИ, следуя которыми, каждый КОМУ HУЖHО это
> опровергнуть, сможет найти правильный ответ.
Весь внимание.
> AB> Т.е. такая группа пакетов не имеет эквивалентного тага в rpm, а
> AB> является продуктом творчества разработчиков, которые пользуются rpm
> AB> как инструментом.
>
> Группа, которая записана в tag'е, она для человека. Классификация
> пакета.
А я и сказал, что такой абстракции в rpm нет. Спасибо, что расшифровали для
тех кто не очень понимает предмета.
> AB> Другими словами, rpm как инструмент, внутри содержит неразрешимую
> AB> проблему.
>
> ...которая является проблемой по всей видимости только для Алексея ;)))
Приятно быть в центре внимания ;) Граждане поддержите апладисментами ;)
> AB> 4.Все инструменты управления пакетами, которые базируются на rpm,
> AB> например yast, для объединения пакетов в группы, требующие
> AB> транзакционной установки, вынуждены создавать собственные описания
> AB> таких групп.
>
> разумеется. Хотите чтоб такую функциональность внесли на уровень rpm?
> Hапишите свои претензии в списки рассыки rpm'а. Там, по крайней мере
> ОТВЕЧАЮТ люди, которые это могут релаьно сделать.
Вроде как выше по треду вы же написали следующее:
>>rpm занимает свою нишу. И RedHat, как основной производитель (да и
>>потребитель) этого продукта, imho СОЗHАТЕЛЬHО не добавляет в rpm мозгов.
>>
>>Им это не выгодно. У них есть up2date, который решает проблемы с
>>обновлениями, и так далее и тому подобное. Как по мне, так вполне
>>отличное решение в разрезе темы "как зарабатывать деньги с использованием
>>OpenSource".
Я с вами здесь соглашаюсь. А предложение мне переписаться с RH воспринимаю
как провокацию ;)
> AB> Hо в базу rpm эта информация не заносится.
>
> зачем хранить то, что можно расчитать? Для экономии времени расчета?
См. далее , именно после такого в постинге обновлений возникают рецепты,
которые включают использование nodeps при ручном апдейте отдельного пакета.
> Есть ли смысл тратить дорогой ресурс "время разработчика", чтоб экономить
> недорогой ресурс "время процессора"?
Это двойные стандарты. Когда в мастдае проблемы решаются экстенсивным путем
в этой же эхе ревнители линукс-вэй громко кричат ФИ, а вот для решения
внутренних проблем эхотага все значит можно ?
> Я думаю что нет смысла. Темболее что разработчики не бездельничают.
Гм-гм ;) Вы таки предлагаете их пожалет ? Я плакалЬ ;) Может хватит того,
что я им денежки плачу ?
> AB> Именно это затрудняет ручное использование rpm в дистрибутивах с
> AB> такими менеджерами.
>
> затрудняет КОГО? Алексея?
Опять аплодисменты ;))) Я раскланиваюсь с публикой ;)
Это конечно хороший ораторский прием свести вопрос к личным проблемам.
Хорошо, что только к лично моим. Спасибо, что не упоминается мой сынишка.
Он экономист и ему вообще с rpm будет трудно разобраться. ;)))
> AB> И это же значит, что добавление "мозгов" rpm за счет внешнего
> AB> менеджера является полумерой, и ничего по-сути не решает.
>
> а что нужно решать-то? Еще инетерсно, _зачем_ оно нужно, какой такой
> качественно положительный результат это решение принесет...
Стоп. Я ведь не спрашиваю кто за такое решение заплатит и кому его
заказывать. Я только хочу заметить, что если абстракция, объединяющая
пакеты в группы, требующие обязательной транзакции, не содержится в базе
rpm, то это недоработка rpm. А вынесение этой абстракции в менеджер
верхнего уровня делает rpm несамостоятельным в применении.
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
PS:А что то Вы сабж поменяли ! А-а-а ! Отмазываете ASP ;))))))
--- ifmail v.2.15dev5
* Origin: homenet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
