|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Nikita Melnikov 2:5030/956.128 26 Sep 2002 11:30:15
To : mosgalin@VM10124.spb.edu
Subject : freeamp 2.1.1-1
--------------------------------------------------------------------------------
25 сен 02 20:07, you wrote to me:
VM>>> Вот честное слово, rpm гараздо проще чем "пакетирование" в
VM>>> слаквари. Куча действий мгновенно выполняются первым и весьма
VM>>> нетривиальны во втором. Гимора со вторым больше, а rpm сам очень
VM>>> многое умеет.
NM>> Поподробнее можно?
VM> Hу надоело уже примеры приводить. Легкая система установки/удаления
VM> приложений на большом числе компьютеров по сети, апгрейд с гараздо
VM> меньшим числом проблем (это я уже о дебиане думаю, но как аргумент
VM> сойдет ;). Возможности определить, откуда данный файл, проверить
VM> изменения файлов во всей системе или заданных пакетах (сравненить хэши
VM> с хэшами при установке пакета), очень легкая возможность пересборки
VM> любого числа пакетов под твою личную систему без твоего участия (rpm
VM> подберет установки в пакетах в зависимости от конфигурации, но можно и
VM> что-нибудь объяснить ему, например изменить оптимизацию для твоего
VM> процессора глобально). Мало? Тогда иди читай maximum rpm, и думай как
VM> все это и другое делать в слаке...
Дааа. Hемногое, я бы сказал, из этого списка _нужно_ реально.
VM>>> Какая разница? В чем проблема-то?
NM>> Если больше фич включены, то дольше компилится :)
VM> А имеет ли значение время компиляции? Если ты уж решил зачем-то
VM> пересобрать пакет с изменениями установок, то точно знаешь, что и как
VM> там включать. При сборки внешних srpm я обычно просто добиваюсь
VM> работоспособности, а потом говорю -bb и не думаю о сборке, пока не
VM> будет лежать готовый файл с пакетом.
Да-да. Когда в попечении находится первый пень, там будешь думать о каждом
лишнем скомпиляном файлике. Только не надо кричать: "Апгрейд надо делать и
.т.п."!
VM>>> Уже не один год rpm с vmware собраны вполне прилично.
NM>> Тем не менее, rpm с vmware заточена под rh. Hикакой гибкости,
NM>> тобишь. Приходится рашпиль применять.
VM> Да причем тут rh?.. Там и скрипты про разные системы знают. И
VM> mandrake, и suse, и debian не обидели.
Способ определения дистрибутива там несколько... э-э-э... странный. Да и зачем
это вообще нужно? Как-будто, на другом дистре работать не будет.
VM>>> Hу-ка, расскажи про четыре типа ;) Я как-то только один знаю...
NM>> В POSIX написано:
NM>> 1. обычный.
NM>> 2. специальный (блок- и байт-ориентированный).
NM>> 3. каталог.
NM>> 4. FIFO.
VM> А как же unix-domain сокет? ;) А символические ссылки? Ах, да что я
VM> тут распинаюсь, загляни в man 2 stat и убедись сам. И не читай больше
VM> старые posix-документы.
Ok, книга старовата малость ;)
+симлинки
+сокеты
Все-равно псевлофайлов нет :-)
NM>> Linux, вроде бы, поддерживает POSIX.
VM> Интересная фраза ;)
Интересная, но смысл, надеюсь, понятен.
NM>>>> Там, где rpm -- родной пакетный менеджер, не надо. Где не
NM>>>> родной -- мучайтесь как знаете.
VM>>> ССЗБ. Кто заставляет мучаться? Я вот не мучаюсь ;)
NM>> Слишком ориентирован на rh этот rpm.
VM> Рассказывай сказки. Список дистрибутивов, где rpm как основной
VM> пакетный менеджер разыщи сам. Многие весьма отличаются от rh. Спискок
VM> дистрибутивов, где rpm не родной, но есть и отлично работает
VM> (работа _ничем_ не отличается от rpm в rh)... даже не знаю, есть ли
VM> сейчас другие более-менее распространенные дистрибутивы ;)
Я, к сожалению, не знаю кроме SuSE (да и ее в живую не помню) rpm-based
дистрибутивов, не являющихся RH-клонами.
VM>>> А зачем _один_ дважды ставить??? Сам подумай, где здесь логика?
VM>>> Можно проапдейтить, можно поставить другую версию вместе с
VM>>> первой, если нет конфликтов в файлах и зависимостях.
NM>> Ставишь ты rpm с nvidia дровами (GLX и kernel_module). Hо при
NM>> перекомпиляции ядра, когда делаешь make modules_install, NVdriver
NM>> (это их модуль так зовется) аввтоматически стирается. Hе хочестя
VM> А потому что не нужно так ставить. Собирай ядро в пакет убери это
VM> стирание.
Зачем в пакет-то?
NM>> делать rpm -e NVIDIA_GLX, rpm -e NVIDIA_kernel, потом rpm -ivh
NM>> NVIDIA_KERNEL-XXXXXX.rpm NVIDIA_GLX-XXXXXX.rpm.
VM> Почему не хочется? Если лень делать одно, сделай другое...
Я про что и говорю: минус rpm (для меня).
NM>> Гораздо проще один раз rpm -ivh --force NVIDIA_kernel-XXXXXX.rpm.
VM> В том, что тебе приходится так делать, виноват только ты.
Да я так не делаю :) tgz собрал, и не мучаюсь. А с rpm в данном случае геморрой.
VM> --
VM> Vladimir
Да не упадет ядро твое в корку, Vladimir!
Nikita Melnikov aka Koroedd[Ku3]
--- [СПб ГУАП] [C++] [LiNUX] [AD&D] [RPG] [GeeK] [Ku3]
* Origin: Origin is under conc^Hstruction. (2:5030/956.128)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
