RPM 4.4.2.1

>Знаете, неспособность разобраться в другом дистрибутиве вистов Вам не добавляет и говорит о костности мышления

Почему-то RedHat, Alt, Asp, Slackware, Ubuntu у меня стояли достаточно долго и без глюков, Debian у меня уже 4 года, видно глюки в Suse это и есть "неспособность разобраться в другом дистрибутиве". Кстати наверное потому-же и винда глючит :).

[offtop] >Нормально - это когда обновление может пройти автоматически, а не >когда раз в неделю надо сидеть за каждой машинкой и тыкать кнопочки. что-то подобное в Ulteo обещают. [/offtop]

Очень сложно раз в недели нажать три кнопки в synaptic :))). Кстати тоже самое можно добавить по cron раз в неделю и ничего не нажимать.

>Нормально - это когда обновление может пройти автоматически, а не когда раз в неделю надо сидеть за каждой машинкой и тыкать кнопочки.

вот именно! поэтому в Debian можно в крон запхать apt-get dist-upgrade, потому что несвоместимости при серьезных обновлениях скомпенсированы скриптами

а в редхате сие невозможна

>Очень сложно раз в недели нажать три кнопки в synaptic :))).

Несколько серверов так обновлять запаришься.

>Кстати тоже самое можно добавить по cron раз в неделю и ничего не нажимать.

Через cron вряд ли ты сможешь определить вариант инсталяции:

>>нормально это когда при обновлении/установки программ установщик в сложных случаях спрашивает тебя о варианте инсталляции а не ты потом роешь по README/UPGRADE

>>xargs * (*) (23.07.2007 20:09:30)

>Почему-то RedHat, Alt, Asp, Slackware, Ubuntu у меня стояли достаточно долго и без глюков, Debian у меня уже 4 года, видно глюки в Suse это и есть "неспособность разобраться в другом дистрибутиве". Кстати наверное потому-же и винда глючит :).

А у меня суся на множестве машин, и не глючит, что я делаю не так? А вот некоторые из упомянутых дистрибутивов таки глючили.

> Через cron вряд ли ты сможешь определить вариант инсталяции

??? что под данной фразой подразумевается?

>??? что под данной фразой подразумевается?

У xargs спроси.

Можно сделать так, чтобы по умолчанию конфиги не трогались и запросы конфигурялок шли лесом.

>Через cron вряд ли ты сможешь определить вариант инсталяции:

по крону собрался делать _инсталляцию_? ну ты даешь!

а апгрейд по крону вполне себе отлично работает

PS: кстати и инсталляция из скриптов оченно неплохо работает

она редко где может понадобиться но местами нужна и в Debian используется для автоматической сборки пакетов под все платформы

выглядит примерно так:

http://buildd.debian.org/fetch.cgi?pkg=fluxbox;ver=1.0%7Erc3-3;arch=mips;stam...

>До хрена. glibc и кучу других библиотек не получится использовать - новые версии - до перезагрузки.

неправда, достаточно перегрузить сервисы использующие этот самый новый глибц, даже apt-get такое умеет (aptitude не пользую)

во-во, вот почему порты (в известной бсд) это не самое лучшее решение....

[sanja@elennet ~]$ lsb_release -d && uname -a && apt-get dist-upgrade --help
Description:    Scientific Linux SL release 4.4 (Beryllium)
Linux elennet.ru 2.6.9-42.0.10.EL #1 Tue Feb 27 08:19:01 CST 2007 i686 i686 i386 GNU/Linux
apt 0.5.15cnc6 для linux i386 собран Apr  5 2005 09:39:53
Использование: apt-get [параметры] команда
               apt-get [параметры] install|remove пакет1 [пакет2 ...]
               apt-get [параметры] source пакет1 [пакет2 ...]

apt-get предоставляет простой командный интерфейс для получения и
установки пакетов. Чаще других используются команды update (обновить)
и install (установить).

Команды:
   update - Получить обновлённые списки пакетов
   upgrade - Произвести обновление
   install - Установить новые пакеты
   remove - Удалить пакеты
   source - Скачать архивы исходников
   build-dep - Установить всё необходимое для сборки исходных пакетов
   dist-upgrade - Обновление системы в целом, см. apt-get(8)
   clean - Удалить скачанные ранее архивные файлы
   autoclean - Удалить давно скачанные архивные файлы
   check - Удостовериться в отсутствии неудовлетворённых зависимостей

Параметры:
  -h  Краткая справка
  -q  Скрыть индикатор процесса
  -qq Не показывать ничего кроме сообщений об ошибках
  -d  Получить пакеты и выйти БЕЗ их установки или распаковки
  -s  Симулировать упорядочение вместо реального исполнения
  -y  Автоматически отвечать 'ДА' на все вопросы
  -f  Пытаться исправить положение если найдены неудовлетворённые зависимости
  -m  Пытаться продолжить если часть архивов недоступна
  -u  Показать список обновляемых пакетов
  -b  Собрать пакет после получения его исходника
  -D  При удалении пакета стремиться удалить компоненты, от которых он зависит
  -V  Подробно показывать номера версий
  -c=? Использовать указанный файл конфигурации
  -o=? Изменить любой из параметров настройки (например: -o dir::cache=/tmp)
Более полное описание доступно на страницах руководства man:
apt-get(8), sources.list(5) и apt.conf(5).

ну и что я сделал не так, почему оно возможно????

ПС: можно и yum update в крон зарядить;)
ППС: изначельно на машинке скентифик 4.1 крутился, и как он плавно и
без падений и глюков превратился в 4.4 - ума не приложу;) три года
как без передыху крутиться и крутиться (это вообще-то RHEL 4))))

>>Да ну? Сегодня апгрейдил glibc. Ничего он мне не перезапускал. И слава богу.

>значит или перезапускать не было необходимости,

По твоему, он должен был перезапустить мне все программы? от glibc зависят все программы

>или ты на rpm сидишь который такого не умеет

Я прочитал внимательно.

>нормально это когда при обновлении программ автоматом апгрейдятся конфиги и конвертятся данные

Вот конфиги трогать не надо - я его, может, сутки писал. На кой мне его обновление?

Конфиги, кстати, кладутся рядом как rpmnew или перезаписываются, а старые выглядят как rpmorig.

>нормально это когда при обновлении/установки программ установщик в сложных случаях спрашивает тебя о варианте инсталляции

Это в каких случаях нужно?

>нормально это когда после обновления пакет ТАК ЖЕ работоспособен как и до обновления

Уже сколько лет на федорах и все работает.

Редхату не нужно, чтобы снилось - у него в реале все пашет. Самый крупный коммерческий дистростроитель.

>а в редхате сие невозможна

yumupgrade есть такой чудесный сервис. Сидит себе и обновляет тебе дистр.

>Конфиги, кстати, кладутся рядом как rpmnew или перезаписываются, а старые выглядят как rpmorig.

конфиги рядом кладутся потому что ума у майнтенеров нет скрипт написать и возможности тоже (rpm)

> Вот конфиги трогать не надо - я его, может, сутки писал. На кой мне его обновление?

> Конфиги, кстати, кладутся рядом как rpmnew или перезаписываются, а старые выглядят как rpmorig.

В дебиане старые версии конфигов также сохраняются рядом.

>>нормально это когда при обновлении/установки программ установщик в сложных случаях спрашивает тебя о варианте инсталляции

> Это в каких случаях нужно?

Например, ввести урл подкомпонента, не вошедшего в пакет по лицензионным или иным причинам. Либо выбрать, какой именно вспомогательный пакет нужно поставить (OR-зависимости рулят).

>>нормально это когда после обновления пакет ТАК ЖЕ работоспособен как и до обновления

> Уже сколько лет на федорах и все работает.

> Редхату не нужно, чтобы снилось - у него в реале все пашет.

Как же, как же. Помню я это «всё работает», если с рхелом ещё более-менее, то Федора — это полный атас. До некоторого уровня действительно почти всё у всех дистров работает. Вот только в дебиане 99.9% установленных в системе пакетов взяты с оф.репозитория, а в федоро-рхелах приходится кучу софта ставить хрен пойми откуда. Естественно, что при этом нет никакой единой багзиллы, нет контролируемого тестирования, инсталяционные скрипты вообще через жопу написаны.

> Самый крупный коммерческий дистростроитель.

мелкософт вообще самый крупный, значит, он самый лучший?

> конфиги рядом кладутся потому что ума у майнтенеров нет скрипт написать и возможности тоже (rpm)

Возможности есть,но это не нужно.Обновления пакетов нужно для латания дыр,т.к. после релиза версии используемого ПО замораживаются.Такой подход у RH и SuSE. По поводу конфигов jackill уже сказал,править их не надо не тупым,ни умным скриптом,почему догадываешься или нет?

Эх!, народ, народ... почитал я что вы тут пишите и непонял вас.. главное в системе *NIX то, что она стабильна, и апдейтерство все идет от мелкомягкости мозга! Когда я ставлю систему - я ее ставлю на годы, и если мне чего не хватает, то никакой менеджер пакетов и апдейтер не поможет реально - все собирается из сырцов (я ASP пользую дома, вынуждено сижу на работе на SuSE, и поддерживаю пачку юзеров на Slackware) - никакой менеджер пакетов не даст вам никогда получить единообразие софта в подобном зоопарке.. а фанатам tgz скажу лично - не обижайтесь, но это убожество, хоть RPM далеко не совершенен, но он лучше чем tgz.. Как показала моя годовая практика со Слакой - эта система хороша до тех пор, пока не попробуешь ее обновить выборочно - зависимости невозможно определить (разве-что на сайте Дебиана :-), а вот с RPM таких проблемм незамечено. Да!, и еще, я что-то давненько не замечал чтобы мои древние конфиги переставали работать с новой версией проги :-) (если не вспомнить про поменявшийся чуть-чуть формат /etc/fstab где-то года три назад).. :-) PS: Больше программ, хороших и разных!

>Возможности есть,но это не нужно.Обновления пакетов нужно для латания дыр,т.к. после релиза версии используемого ПО замораживаются. Такой подход у RH и SuSE.

Такой подход у всех вменяемых дистростроителей у которых имеется такое понятие как релиз. Но дело в том что периодически нужно таки делать dist-upgrade. И вот тут очень удобно когда при обновлении пакета тебе сообщат о том что, допустим, поменялся формат конфига, предложат его сконвертировать, напомнят что нужно в него заглянуть и убедиться что там всё в порядке. А не просто положат рядом новый конфиг и сиди думай сам что и где нужно поправить.

> А не просто положат рядом новый конфиг и сиди думай сам что и где нужно поправить.

При апргрейде версии в сусе проявлялась несовместимости версий пакетов и они удалялись инсталятором,хотя я предпочитаю сохранять ручками необходимые конфиги,а потом их внедрять,т.ч. почти всегда ставлю свежую установку. Так ИМХО надёжнее,чем потом косяки вылавливать.

>RPM - Rip package manager

+10000000

:D

>И вот тут очень удобно когда при обновлении пакета тебе сообщат о том что, допустим, поменялся формат конфига, предложат его сконвертировать, напомнят что нужно в него заглянуть и убедиться что там всё в порядке. А не просто положат рядом новый конфиг и сиди думай сам что и где нужно поправить.

Это есть в Арче - после обновления пакета, тебе выводятся пакета, которые _опционально_ зависимы от пакета и рекомендации, типа - синтаксис конфига изменился, какой-то файл конфига отпал за ненадобностью.. etc.

>конфиги рядом кладутся потому что ума у майнтенеров нет скрипт написать и возможности тоже (rpm)

Напиши-ка мне скрипт для того, чтобы обновить конфиги PHP4 на PHP5, и чтобы при этом все старые программы на PHP гарантированно работали.

Он наверно о SUSE 8 думал живет прошлым

> инсталляционные скрипты майнтенеры в rpm уже научились вставлять? нет? ф топку!

Это вы о чем? Забыли почитать? RTFM?

>Возможности есть,но это не нужно.

вот и в венде есть возможности, например не работать под рутом но стадо идиотов считает что это не нужно, поэтому куча программ не под рутом работать не может, а поэтому получается что и возможность не работать под рутом в венде эфемерна.

ровно так же и с этим rpm и "возможностью" писать для него скрипты

>По поводу конфигов jackill уже сказал,править их не надо не тупым,ни умным скриптом,почему догадываешься или нет?

так jackill глупость сказал просто потому что он не видел как это может работать

>Когда я ставлю систему - я ее ставлю на годы, и если мне чего не хватает, то никакой менеджер пакетов и апдейтер не поможет реально - все собирается из сырцов

чего мне не хватает в системе я тоже собираю из сырцов... в пакет

а потом устанавливаю

>Напиши-ка мне скрипт для того, чтобы обновить конфиги PHP4 на PHP5, и чтобы при этом все старые программы на PHP гарантированно работали.

посмотри в пакет php5 Debian'а, скорее всего такой скрипт там есть

(я не пользую php)

>Это вы о чем? Забыли почитать? RTFM?

я очень однозначно выразился. если RTFM не удосуживаются читать разработчики дистрибутива, то фтопку и RTFM и разработчиков и дистрибутив

> инсталляционные скрипты майнтенеры в rpm уже научились вставлять? нет? ф топку!

Так PREIN, POSTIN, PREUN и POSTUN уже сто лет как вроде?

> Напиши-ка мне скрипт для того, чтобы обновить конфиги PHP4 на PHP5, и чтобы при этом все старые программы на PHP гарантированно работали.

Это разные пакеты. Если сильно утрировать, то твоё предложение можно переработать так: "... чтобы обновить конфиги proftpd на openssh и чтобы при этом.." :)

>ровно так же и с этим rpm и "возможностью" писать для него скрипты

к чему ты выделил это слово?

наличие в deb такой возможности by design не говорит о том, что она обязательно и на 100% корректно будет использована

>Это разные пакеты.

А если обновлять PHP 5.0 на 5.2, все будет работать и без изменений конфигов. С 99% софта изменения, требущие изменения конфигов/данных, происходят лишь при изменении мажорной версии. Так что не понимаю, в чем проблема.

на две страницы обсуждения того что уже давным давно реализовано в gentoo

> инсталляционные скрипты майнтенеры в rpm уже научились вставлять?

Мля уже фиг его знает сколько лет в RPM есть postinstall, который замечательно все делает. Например, вызывает mkinitrd после установки нового ядра, или ldconfig после установки библиотек, перезапускает сервис если это надо и так далее.

> ф топку!

Ага. "Pнатокофф" в топку. +1

> нормально это когда после обновления пакет ТАК ЖЕ работоспособен как и до обновления

Да-да, покажешь всем как апач-1 в сложной конфигурации апгрейдится в апач-2? Или там как самба с версии 2 на 3 - опять же не с дефолтовым конфигом апдейтится?

apache не апгрейдится в apache2, это разные пакеты. Так же как php4 и php5.

А с самбой насколько я помню проблем не было. Во всяком случае при апгрейде с woody до sarge. Было сказано что какие-то параметры устарели, какие-то добавились, предложено автоматически их заменить и предъявлен результат для аудита.

самбы 3 не еще видел, а вот на вторую версию я когда-то благополучно переехал

> во-во, вот почему порты (в известной бсд) это не самое лучшее решение....

man pkgtools.conf

Все в FreeBSD делается portupgrade'ом, только голову приложить надо.

>Все в FreeBSD делается portupgrade'ом, только голову приложить надо.

FBSD покамест Debian до ума не довел а потому не стоит с ней ковыряться ;)

> А если обновлять PHP 5.0 на 5.2

Причём тут 5.0 и 5.2? Ты спрашивал про php4 и php5. Я тебе ответил.

>это разные пакеты. Так же как php4 и php5.

а что будет при обновлении на ленни у которого не будет 4 пых-пыха ?

останется - удалять его никто не будет

> Люблю когда RPM правильный вот DEB правильный RPM.

Это покруче, чем "казнить нельзя помиловать"!

Прошу прощения за глупый вопрос. Как эта версия 4.4.2.1 соотносится с версиями 4.4.2, 4.4.3, 4.4.4, 4.4.5, 4.4.6, 4.4.7, 4.4.8 и 4.4.9 отсюда: http://wraptastic.org/pub/rpm-4.4.x/ ? И исправлен ли в 4.4.2.1 баг с порчей базы при прерывании обновления: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 ?

Сегодня официальный RPM это rpm.org

Они начали с 4.4.2. Это официально поддерживаемая RH и Novell версия. https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00003.html

Версии старше это творчество товарищей с wraptastic.org (Jeff Johnson???). В RH и Suse они не используются (там сильно патчат 4.4.2). Водятся только в Mandriva и еще какой-то фигне - я если честно не уверен, что официально в мандриве водятся версии старше 4.4.2.

Поправьте меня если я не прав.

Про указанный баг ничего сказать не могу. Давайте следить за официальным апстримом.

Нифигасебе! У этих кренделей с wraptastic в rpm-devel даже версия 5.0 водится! ftp://wraptastic.org/pub/rpm-devel/