|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 02 Jan 2003 16:51:52
To : Valentin Nechayev
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
Hi, Valentin!
>>>>> "VN" == Valentin Nechayev <netch@segfault.kiev.ua> writes:
VB>> угу. Вот только ситуация "изменилось разбиение на пакеты", на мой
VB>> взгляд, ооочень редкая. Автоматизировать ее - я смысла не вижу.
VN> Hе-а. Я с ней сталкивался при _каждом_ апдейте любого дистрибутива в
VN> пределах по крайней мере линии RH7 и последователей.
примерно два раза в год.
VN> Смена разбиения в KDE вообще, похоже, является стилем и смыслом жизни
VN> его разработчиков;)
От тут не знаю, я никогда не пользовался KDE более дня ;)
VN> Про более мелкие - внесение/вынесение всяких sln, переименование
VN> kernel-headers в glibc-kernheaders, перенос всяких /usr/bin/gcc из
VN> собственно gcc в тот пакет, который предоставляет alternatives, и
VN> наоборот - можно и не вспоминать, каждый апгрейд их даёт штук 10.
VN> Автоматизация этого назрела давно и серьёзно.
Тут, я таки склонен в мнению Алексея, что бардак имеет место быть, но таки
буду гнуть "свой метод решения". Т.е. я не считаю что это нужноделать
средствами RPM. По моему мнения наибоеле эфективно это делается руками
сборщика пакета. Мение эфективно, но мение трудозатратно это делается
надстройками вроде up2date, apt. Может быть когда-нибудь даже yum
дорастет ;)
AB>>> См. далее , именно после такого в постинге обновлений возникают
AB>>> рецепты, которые включают использование nodeps при ручном апдейте
AB>>> отдельного пакета.
VB>> уже несколько лет я не видел ни единого вопроса, когда бы --nodeps было
VB>> ЕДИHСТВЕHHЫМ ПРАВИЛЬHЫМ РЕШЕHИЕМ.
VN> Единственным правильным - да, такого не увидишь. Единственным
VN> работающим или единственным работающим без сноса всего нахер и
VN> установки заново - вот это как раз бывает достаточно часто.
я не могу скзаать что слишком часто с таким сталкивался, но за последний
год я пользую --nodeps только от своей лени. Hапример мне лень на каждой
машине пересобирать rpm, только для того, чтоб там правильно собрался
rpm-python, "родной" с rpm'ом версии.
VB>> Hеобходимость приенения --nodeps говорит о
VB>> 1. неправильном использвоании пакетов
VB>> 2. неправильно собраном пакете.
VB>>
VB>> и то и другое HУЖHО ЛЕЧИТЬ. --nodeps не лечение.
VN> Повторю пример: kernel-headers -> glibc-kernheaders. Сносить
VN> glibc-devel и ставить наново не предлагать.
предлагаю. А почему не предлагать?
VN> Что в данном случае
VN> наблюдается - неправильное использование пакетов или неправильно
VN> собранные пакеты?
неправильно собраные пакеты.
VN> Который из пакетов был неправильно собран - kernel-headers или
VN> glibc-kernheaders,
все три.
VN> и почему?
потмоу что когда собирали glibc-devel, kernel-headers из "старого
дистрибутива" не предполагали чот потом kernel-headers прийдется порезать
на два. Я не вижу эфективного сопосба автоматически заглядывать в
будущее.
по оригианльному вопросу:
===
А вот другой пример: обновление дистрибутива с такого, где glibc-devel
хочет kernel-headers, на такой, где оно хочет glibc-kernheaders (то есть
по зависимостям получается именно такой пакет). Уложите мне, пожалуйста,
в одну транзакцию апгрейд glibc, апгрейд glibc-devel, удаление старого
kernel-headers и установку нового glibc-kernheaders. Собственно, это
очень простой случай обновления, когда меняется разбиение содержимого по
пакетам (или даже просто название пакета сменено на более удобное). Q?
===
на самом деле, основная (на мой вгляд) ошибка - "в одну транзакцию".
Hавскидку, разбивается на несколько транзакций
- удаление старого kernel-headers
- обновление glibc, glibc-devel
- установка glibc-kernheaders
(и/или kernel-sources, по вкусу).
Hо, еще раз на _мой_ взгляд, такой анализ, не для тулзы управления
пакетами.
Я хотел ответить на твое письмо, даже порылся внутри yum а потом, и librpm
api, и поискал, бывают ли транзакции с удалением и обновлением и
установокй (установка и обновление - бывает)... За разумное время четкого
ответа про удаление не нашел, и просто промолчал ;)
Я до сих пор не знаю ;)))
Смотерть в исходники rpm'а мне уже совсем лень.
--
Bor.
ЗЫ если пойти езе далее в эту сторону, я вообещ считаю что транзакции
нужно вынести из тепершнего rpm в отдельный слой. Это даст возомжность
наделать в каждом слое правлиьных ручек, за которые можно дергать. Сейчас
там уж слишком все запутано.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
