[sisyphus] php: new config files structure???

[sisyphus] php: new config files structure???

[Andrey Khavryuchenko]

Hi!

После какого-то апгрейда у меня отвалился php-mysql.  Обнаружил следующее:

/etc/php/mod_php/php.ini:
[...]

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
;
; If you wish to have an extension loaded automatically, use the following
; syntax:
;
;   extension=modulename.extension
;
; For example, on Windows:
;
;   extension=msql.dll
;
; ... or under UNIX:
;
;   extension=msql.so
;
; Note that it should be the name of the module only; no directory information 
; needs to go here.  Specify the location of the extension with the
; extension_dir directive above.

; At the ALT Linux this section don't need any more. Use /etc/php.d for it.

Последнее, мягко говоря, несколько неверно, ибо /etc/php.d отсутствует, а
внятного примера в /etc/php/mod_php/php.d также нет.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] php: new config files structure???

[Alexey Gladkov]

On Fri, Nov 07, 2003 at 06:46:45PM +0200, Andrey Khavryuchenko wrote:
> Hi!
> 
> После какого-то апгрейда у меня отвалился php-mysql.  Обнаружил следующее:
> 
> /etc/php/mod_php/php.ini:
> [...]

все правильно.

> 
> ;;;;;;;;;;;;;;;;;;;;;;
> ; Dynamic Extensions ;
> ;;;;;;;;;;;;;;;;;;;;;;
> ;
> ; If you wish to have an extension loaded automatically, use the following
> ; syntax:
> ;
> ;   extension=modulename.extension
> ;
> ; For example, on Windows:
> ;
> ;   extension=msql.dll
> ;
> ; ... or under UNIX:
> ;
> ;   extension=msql.so
> ;
> ; Note that it should be the name of the module only; no directory information 
> ; needs to go here.  Specify the location of the extension with the
> ; extension_dir directive above.
> 
> ; At the ALT Linux this section don't need any more. Use /etc/php.d for it.
> 
> Последнее, мягко говоря, несколько неверно, ибо /etc/php.d отсутствует, а
> внятного примера в /etc/php/mod_php/php.d также нет.
> 

Вы правы этот коментарий устарел .... конечно же в /etc/php/*
По поводу примера... я писал в этот список рассылки о новой схеме
расположения файлов конфигурации.

Кроме того в /usr/share/doc/php-common-4.3.4/php-packaging.readme
лежит продублированная в рассылке информация.

---
Rgrds, legion

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Alexey,

"AG" == Alexey Gladkov wrote:

 AG> On Fri, Nov 07, 2003 at 06:46:45PM +0200, Andrey Khavryuchenko wrote:
 >> Hi!
 >> 
 >> После какого-то апгрейда у меня отвалился php-mysql.  Обнаружил следующее:
 >> 
 >> /etc/php/mod_php/php.ini:

[...]

 >> ; At the ALT Linux this section don't need any more. Use /etc/php.d for it.
 >> 
 >> Последнее, мягко говоря, несколько неверно, ибо /etc/php.d отсутствует, а
 >> внятного примера в /etc/php/mod_php/php.d также нет.

 AG> Вы правы этот коментарий устарел .... конечно же в /etc/php/*
 AG> По поводу примера... я писал в этот список рассылки о новой схеме
 AG> расположения файлов конфигурации.

 AG> Кроме того в /usr/share/doc/php-common-4.3.4/php-packaging.readme
 AG> лежит продублированная в рассылке информация.

Так может, стоит об том упомянуть в конфиге?  И, моежт быть, сделать так,
чтобы php-mysql включался ппри его установке?

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

On Sat, Nov 08, 2003 at 07:46:56PM +0200, Andrey Khavryuchenko wrote:
> 
>  AG> Кроме того в /usr/share/doc/php-common-4.3.4/php-packaging.readme
>  AG> лежит продублированная в рассылке информация.
> 
> Так может, стоит об том упомянуть в конфиге?  И, моежт быть, сделать так,

о новом положении переехавших частей конфига в php.ini написано...
остальную информацию можно найти в стандартном месте... где собственно она
и лежит.

> чтобы php-mysql включался ппри его установке?
> 

все модули в новой схеме после установки пакета сразу включаются.

---
Rgrds, legion

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Alexey,

"AG" == Alexey Gladkov wrote:

 AG> On Sat, Nov 08, 2003 at 07:46:56PM +0200, Andrey Khavryuchenko wrote:

 AG> Кроме того в /usr/share/doc/php-common-4.3.4/php-packaging.readme
 AG> лежит продублированная в рассылке информация.
 >> 
 >> Так может, стоит об том упомянуть в конфиге?  И, моежт быть, сделать так,

 AG> о новом положении переехавших частей конфига в php.ini написано...
 AG> остальную информацию можно найти в стандартном месте... где собственно она
 AG> и лежит.

Увы, неочевидно, если нерегулярно читаешь список рассылки.

 >> чтобы php-mysql включался ппри его установке?

 AG> все модули в новой схеме после установки пакета сразу включаются.

Таки да.  А при dist-upgrade - нет.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1076 bytes --]

В сообщении от Пн 10 Ноя 2003 11:16 Andrey Khavryuchenko написал(a):
>  AG> о новом положении переехавших частей конфига в php.ini написано...
>  AG> остальную информацию можно найти в стандартном месте... где собственно
> она AG> и лежит.
>
> Увы, неочевидно, если нерегулярно читаешь список рассылки.
Да, таки правильно было бы там упомянуть о том, как это сделать рученьками.
А если кто-то не читает рассылку вообще???

>  >> чтобы php-mysql включался ппри его установке?
>  AG> все модули в новой схеме после установки пакета сразу включаются.
> Таки да.  А при dist-upgrade - нет.
Подтверждаю.
И ведь ничего сложного, чтобы написать в стд.месте,  или же даже в 
/etc/php/<..>/README.ALT (например), что можно просто скопировать
"рученьками" оттуда на туда 
cp /usr/share/php/extconf/mysql/config /etc/php/mod_php/php.d/mysql.ini
и всё заработает...
А то там (php-packaging.readme) концептуальная "муть" в вопросах данной 
проблемы. Ну я вот за 10 мин. догнал, а подчиненный "начинающий" админ не 
догнал... :(

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: php: new config files structure???

[Leonid B. Sysoletin]

В сообщении от 10 Ноябрь 2003 14:19 вы написали:
> >  AG> о новом положении переехавших частей конфига в php.ini написано...
> >  AG> остальную информацию можно найти в стандартном месте... где
> > собственно она AG> и лежит.
> > Увы, неочевидно, если нерегулярно читаешь список рассылки.
> Да, таки правильно было бы там упомянуть о том, как это сделать рученьками.
> А если кто-то не читает рассылку вообще???

Не читает рассылку, пользуясь Сизифом? Тады он сам себе злобный буратина.

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru, webmaster@bdo.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]
[Team Я люблю свою фортунку] [Team Фортунка в переписку не вступает]

There is no education that is not political.  An apolitical
education is also political because it is purposely isolating.

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

В сообщении от Пн 10 Ноя 2003 13:22 Leonid B. Sysoletin написал(a):

> > Да, таки правильно было бы там упомянуть о том, как это сделать
> > рученьками. А если кто-то не читает рассылку вообще???
>
> Не читает рассылку, пользуясь Сизифом? 
> Тады он сам себе злобный буратина.
Ну не все "буратины" могут себе позволить толстый канал в инет, а некоторые, 
видимо, особенно буратинистые, не позволяют себе инте вообще.
А Сизиф юзают на болванках. Случаи оффлайнового апдейта в истории существуют.
Я соглаен, что это не есть гут, но а "Что делать?" (С) Чернышевский ;)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

Re: [sisyphus] Re: php: new config files structure???

[Leonid B. Sysoletin]

В сообщении от 10 Ноябрь 2003 14:30 Nick Fedchik написал(a):
> > > Да, таки правильно было бы там упомянуть о том, как это сделать
> > > рученьками. А если кто-то не читает рассылку вообще???
> > Не читает рассылку, пользуясь Сизифом?
> > Тады он сам себе злобный буратина.
> Ну не все "буратины" могут себе позволить толстый канал в инет, а
> некоторые, видимо, особенно буратинистые, не позволяют себе инте вообще.
> А Сизиф юзают на болванках. Случаи оффлайнового апдейта в истории
> существуют. Я соглаен, что это не есть гут, но а "Что делать?" (С)
> Чернышевский ;)

Гы. Подписаться на болваночные архивы рассылки.
Ещё раз гы.

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru, webmaster@bdo.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]
[Team Я люблю свою фортунку] [Team Фортунка в переписку не вступает]

The computer can't tell you the emotional story.  It can give you the exact
mathematical design, but what's missing is the eyebrows.
- Frank Zappa

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

On Mon, Nov 10, 2003 at 01:19:01PM +0200, Nick Fedchik wrote:
> Да, таки правильно было бы там упомянуть о том, как это сделать рученьками.
> А если кто-то не читает рассылку вообще???
> 

а документацию поставляемую вместе с пакетами этот кто-то читает ? 
если тоже нет, то тут я просто бессилен. 

---
Rgrds, legion

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Leonid,

"LBS" == Leonid B Sysoletin wrote:

 LBS> Гы. Подписаться на болваночные архивы рассылки.
 LBS> Ещё раз гы.

А то, что банально может не оказаться времени на чтение всего списка?  
Этот случай, конечно, чинится за 5 минут, не глядя в доку, но всё равно,
остаётся вопрос "А нахрена, собственно?"

Или это у нас (пользователе-разработчиков Сизифа) начинает вырабатываться
снобизм: "кто не допёр, тот сам себе злобный буратина".  Если так, то
предлагаю (1) ориентироваться на obfurscated c, perl, etc content
guidelines и (2) заранее предупредить остальных, чтобы вовремя успели
спрыгнуть.

IMO проще и эффективнее вставить ещё одну строку в дефолный
/etc/php/<mod>/php.ini со ссылкой на соответствующий /usr/share/doc/php*/*,
чем ставить пальцЫ.  _Мне_ прозрачная работоспособность важнее чем.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Alexey,

"AG" == Alexey Gladkov wrote:

 AG> On Mon, Nov 10, 2003 at 01:19:01PM +0200, Nick Fedchik wrote:
 >> Да, таки правильно было бы там упомянуть о том, как это сделать рученьками.
 >> А если кто-то не читает рассылку вообще???
 >> 

 AG> а документацию поставляемую вместе с пакетами этот кто-то читает ? 
 AG> если тоже нет, то тут я просто бессилен. 

Бессилен что?  Добавить ещё одну строку комментария в
/etc/php/mod_php/php.ini?  

Патч прислать?

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1200 bytes --]

В сообщении от Пн 10 Ноя 2003 13:48 Alexey Gladkov написал(a):
> On Mon, Nov 10, 2003 at 01:19:01PM +0200, Nick Fedchik wrote:
> > Да, таки правильно было бы там упомянуть о том, как это сделать
> > рученьками. А если кто-то не читает рассылку вообще???
> а документацию поставляемую вместе с пакетами этот кто-то читает ?
> если тоже нет, то тут я просто бессилен.
Читает. В моём случае так и было.
Я упоминал, что прочтение доки из стандартного места 
(/usr/share/doc/<pkg-name>) не способствовало быстрому устранению проблемы.
Лично я пропустил предыдущие упоминания об изменениях в конфигурационных 
файлах, но мой личный опыт в данном случае мне помог - я быстро понял новую 
концепцию для конфигурационных файлов и произвел необходимые изменения.

Но я полагаю что у некоторых администраторов на решение данной проблемы 
потребуется сравнительно большой интервал времени. И на работающих системах с 
повышенными требованиями к доступности информации возникнет прецендент с 
негативными для администратора системы последствиями. 

Поэтому я считаю, что там целесообразно рассмотреть данный случай и указать  
сценарий для его решения.


-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: php: new config files structure???

[Leonid B. Sysoletin]

В сообщении от 10 Ноябрь 2003 14:54 Andrey Khavryuchenko написал(a):
>  LBS> Гы. Подписаться на болваночные архивы рассылки.
>  LBS> Ещё раз гы.
> А то, что банально может не оказаться времени на чтение всего списка?
> Этот случай, конечно, чинится за 5 минут, не глядя в доку, но всё равно,
> остаётся вопрос "А нахрена, собственно?"

Вы так говорите, будто Сизиф - это что-то, что вам суют под дулом пистолета.
Если нет времени разбираться - используй уже разобранное. В данном случае - 
стабильные дистрибутивы типа Мастера.

> Или это у нас (пользователе-разработчиков Сизифа) начинает вырабатываться
> снобизм: "кто не допёр, тот сам себе злобный буратина".  Если так, то
> предлагаю (1) ориентироваться на obfurscated c, perl, etc content
> guidelines и (2) заранее предупредить остальных, чтобы вовремя успели
> спрыгнуть.

Это тут при чём?

> IMO проще и эффективнее вставить ещё одну строку в дефолный
> /etc/php/<mod>/php.ini со ссылкой на соответствующий /usr/share/doc/php*/*,
> чем ставить пальцЫ.  _Мне_ прозрачная работоспособность важнее чем.

Угу. И ещё в пять тыщ мест, где потенциально можно облажаться...

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru, webmaster@bdo.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]
[Team Я люблю свою фортунку] [Team Фортунка в переписку не вступает]

Simon's Law:
	Everything put together falls apart sooner or later.

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

On Mon, Nov 10, 2003 at 02:01:31PM +0200, Nick Fedchik wrote:
> > а документацию поставляемую вместе с пакетами этот кто-то читает ?
> > если тоже нет, то тут я просто бессилен.
> Читает. В моём случае так и было.
> Я упоминал, что прочтение доки из стандартного места 
> (/usr/share/doc/<pkg-name>) не способствовало быстрому устранению проблемы.
> Лично я пропустил предыдущие упоминания об изменениях в конфигурационных 
> файлах, но мой личный опыт в данном случае мне помог - я быстро понял новую 
> концепцию для конфигурационных файлов и произвел необходимые изменения.
> 
> Но я полагаю что у некоторых администраторов на решение данной проблемы 
> потребуется сравнительно большой интервал времени. И на работающих системах с 
> повышенными требованиями к доступности информации возникнет прецендент с 
> негативными для администратора системы последствиями. 
>

Если администратор ставит какие-нибудь пакеты из нестабильного
репозитория, то в его интересах читать ну если не всю рассылку, то хотябы
только то что относится к пакетам которые он использует. Потому что не
всегда получается мягкий переезд (см. ниже)

> Поэтому я считаю, что там целесообразно рассмотреть данный случай и указать  
> сценарий для его решения.
> 

Дело в том, что данная проблема у меня не воспроизводится ... опять же я
писал, что новая сборка находилась более недели на тестировании в
Daedalus и просил заинтересованых администраторов протестировать ... я не
получил ни одного писльма по поводу данной проблемы. 

опишите (лучше с логом) порядок выших действий и проблему более детально 
... т.е. что обновлялось и в каком порядке. Дело в том, что из сказанного 
вами выше я понял, что конфиги соответствующих модулей не были установлены из 
/usr/share/php/extconf в /etc/php/<mod>/php.d 
это может произойти только в том случае, если был нарушен порядок
установки новых версий пакетов в систему...
сейчас я могу только посоветовать сделать --reinstall 

Хочу опять же напомнить(я об этом писал), что в этой сборке есть ошибка 
проявляющаяся при полном удалении php... эта ошибка возникает из-за того, 
что rpm не отслеживает правильно зависимости при удалении... после удаления 
остаются файлы пренадлежащие php 
как временное решение пока не будет исправлен rpm я могу посоветовать
сначала удалять все кроме php-common, после чего можно удалить php-common.

---
Rgrds, legion

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Leonid,

"LBS" == Leonid B Sysoletin wrote:

 LBS> В сообщении от 10 Ноябрь 2003 14:54 Andrey Khavryuchenko написал(a):
 LBS> Гы. Подписаться на болваночные архивы рассылки.
 LBS> Ещё раз гы.
 >> А то, что банально может не оказаться времени на чтение всего списка?
 >> Этот случай, конечно, чинится за 5 минут, не глядя в доку, но всё равно,
 >> остаётся вопрос "А нахрена, собственно?"

 LBS> Вы так говорите, будто Сизиф - это что-то, что вам суют под дулом
 LBS> пистолета.  Если нет времени разбираться - используй уже
 LBS> разобранное. В данном случае - стабильные дистрибутивы типа Мастера.

Я, Андрей Хаврюченко, выбрал Сизиф по собственной воле, находясь в здравом
уме и трезвой памяти.

И я не понимаю, почему Вы, Леонид, возлагаете на _человека_ задачи[1], которые
элементарно упрощаются добавлением 1 (одной) стороки комментария в конфиг.
Объясните?

Или мне прислать патч?

 >> Или это у нас (пользователе-разработчиков Сизифа) начинает вырабатываться
 >> снобизм: "кто не допёр, тот сам себе злобный буратина".  Если так, то
 >> предлагаю (1) ориентироваться на obfurscated c, perl, etc content
 >> guidelines и (2) заранее предупредить остальных, чтобы вовремя успели
 >> спрыгнуть.

 LBS> Это тут при чём?

Да при том, что Ваша реплика воспринимается как "ты не удовлетворяешь мои
требованиям к админу, ergo пошёл нафиг".

Ибо если продолжать этот принцип, то вся система должна собираться руками
из разрозненных tar.gz с обязательным предварительным прочтением
исходников. 

Зачем, если можно проще?

 >> IMO проще и эффективнее вставить ещё одну строку в дефолный
 >> /etc/php/<mod>/php.ini со ссылкой на соответствующий /usr/share/doc/php*/*,
 >> чем ставить пальцЫ.  _Мне_ прозрачная работоспособность важнее чем.

 LBS> Угу. И ещё в пять тыщ мест, где потенциально можно облажаться...

Можно первую полусотню поимённо?


Footnotes: 
[1]  тотальное чтение списка рассылки sisyphus@

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Alexey,

"AG" == Alexey Gladkov wrote:

 AG> Дело в том, что данная проблема у меня не воспроизводится ... опять же я
 AG> писал, что новая сборка находилась более недели на тестировании в
 AG> Daedalus и просил заинтересованых администраторов протестировать ... я не
 AG> получил ни одного писльма по поводу данной проблемы. 

У меня не mission critical машина, поэтому Дедал не трогаю.  Как только
появился вопрос - отписал.

 AG> опишите (лучше с логом) порядок выших действий и проблему более детально 
 AG> ... т.е. что обновлялось и в каком порядке. 

Был дежурный dist-upgrade, логов, естественно, не сохранилось.

 AG> Дело в том, что из сказанного вами выше я понял, что конфиги
 AG> соответствующих модулей не были установлены из /usr/share/php/extconf
 AG> в /etc/php/<mod>/php.d это может произойти только в том случае, если
 AG> был нарушен порядок установки новых версий пакетов в систему...
 AG> сейчас я могу только посоветовать сделать --reinstall

Уже сделал.  Файлы появились.  По видимому сыграла ошибка, которую ты
описал ниже.

 AG> Хочу опять же напомнить(я об этом писал), что в этой сборке есть ошибка 
 AG> проявляющаяся при полном удалении php... эта ошибка возникает из-за того, 
 AG> что rpm не отслеживает правильно зависимости при удалении... после удаления 
 AG> остаются файлы пренадлежащие php 
 AG> как временное решение пока не будет исправлен rpm я могу посоветовать
 AG> сначала удалять все кроме php-common, после чего можно удалить php-common.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

On Mon, Nov 10, 2003 at 03:53:14PM +0200, Andrey Khavryuchenko wrote:
> Я, Андрей Хаврюченко, выбрал Сизиф по собственной воле, находясь в здравом
> уме и трезвой памяти.
> 
> И я не понимаю, почему Вы, Леонид, возлагаете на _человека_ задачи[1], которые
> элементарно упрощаются добавлением 1 (одной) стороки комментария в конфиг.
> Объясните?
> 

я могу попробовать ответить ... раз уж вы выбрали Сизиф (тем более
находясь в здравом уме) должны понимать что это нестабильный репозиторий и
все анонсы об изменениях приходят в пакетах приходят в этот список. Если
вы по каким-либо причинам не можете читать этот список вам необходимо
перед установкой пакета ознакомиться с его changelog`ом

rpm -q --changelog php-common | grep -A10 20031017      
* Птн Окт 17 2003 Alexey Gladkov <legion@altlinux.ru>
* 1:4.3.4-alt0.cvs20031017

- New CVS snapshot.
- New scheme loading extensions. From now all extensions in 
  the /etc/<SAPI>/php.d/*.ini (Fixed #2940). This scheme fixed #2532.
  For more information please read documentation.
- New scheme creating/installing SAPI.
  + each SAPI may have own config file;
  + each SAPI may have own extensions kit.
- spec changes.

в противном случае в не сможете нормально реагировать на изменения.

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

> Или мне прислать патч?
> 
> 
> Footnotes: 
> [1]  тотальное чтение списка рассылки sisyphus@
> 

---
Rgrds, legion

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Alexey,

"AG" == Alexey Gladkov wrote:

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

Спасибо, что не услышали.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

On Mon, Nov 10, 2003 at 03:55:20PM +0200, Andrey Khavryuchenko wrote:
> У меня не mission critical машина, поэтому Дедал не трогаю.  Как только
> появился вопрос - отписал.
>

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

> 
> Был дежурный dist-upgrade, логов, естественно, не сохранилось.
> 

[...]

> 
> Уже сделал.  Файлы появились.  По видимому сыграла ошибка, которую ты
> описал ниже.
> 

это явно не та ошибка, которую я описал... но воспроизвести я ее не могу.

---
Rgrds, legion

Re: [sisyphus] Re: php: new config files structure???

[Leonid B. Sysoletin]

В сообщении от 10 Ноябрь 2003 16:53 Andrey Khavryuchenko написал(a):
>  LBS> В сообщении от 10 Ноябрь 2003 14:54 Andrey Khavryuchenko написал(a):
>  LBS> Гы. Подписаться на болваночные архивы рассылки.
>  LBS> Ещё раз гы.
>  >> А то, что банально может не оказаться времени на чтение всего списка?
>  >> Этот случай, конечно, чинится за 5 минут, не глядя в доку, но всё
>  >> равно, остаётся вопрос "А нахрена, собственно?"
>  LBS> Вы так говорите, будто Сизиф - это что-то, что вам суют под дулом
>  LBS> пистолета.  Если нет времени разбираться - используй уже
>  LBS> разобранное. В данном случае - стабильные дистрибутивы типа Мастера.
> Я, Андрей Хаврюченко, выбрал Сизиф по собственной воле, находясь в здравом
> уме и трезвой памяти.
> И я не понимаю, почему Вы, Леонид, возлагаете на _человека_ задачи[1],
> которые элементарно упрощаются добавлением 1 (одной) стороки комментария в
> конфиг. Объясните?

Время должно быть либо на чтение доков и changelog'ов, либо на тупое копание в 
доке.

>  >> Или это у нас (пользователе-разработчиков Сизифа) начинает
>  >> вырабатываться снобизм: "кто не допёр, тот сам себе злобный буратина". 
>  >> Если так, то предлагаю (1) ориентироваться на obfurscated c, perl, etc
>  >> content guidelines и (2) заранее предупредить остальных, чтобы вовремя
>  >> успели спрыгнуть.
>  LBS> Это тут при чём?
> Да при том, что Ваша реплика воспринимается как "ты не удовлетворяешь мои
> требованиям к админу, ergo пошёл нафиг".

То есть? Если админ лихорадочно тащит с сети все неопробованные новинки, то 
мне его и дальше крутым админом называть?

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru, webmaster@bdo.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]
[Team Я люблю свою фортунку] [Team Фортунка в переписку не вступает]

The worst part of having success is trying to find someone who is happy for 
you.
		-- Bette Midler

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 4273 bytes --]

В сообщении от Пн 10 Ноя 2003 14:57 Alexey Gladkov написал(a):

> > Но я полагаю что у некоторых администраторов на решение данной проблемы
> > потребуется сравнительно большой интервал времени. И на работающих
> > системах с повышенными требованиями к доступности информации возникнет
> > прецендент с негативными для администратора системы последствиями.
>
> Если администратор ставит какие-нибудь пакеты из нестабильного
> репозитория, то в его интересах читать ну если не всю рассылку, то хотябы
> только то что относится к пакетам которые он использует. 
Я это не отрицаю, и наоборот - настоятельно рекомендую.

> Потому что не всегда получается мягкий переезд (см. ниже)
Бывает, к сожалению... 

> > Поэтому я считаю, что там целесообразно рассмотреть данный случай и
> > указать сценарий для его решения.
> Дело в том, что данная проблема у меня не воспроизводится ... опять же я
> писал, что новая сборка находилась более недели на тестировании в
> Daedalus и просил заинтересованых администраторов протестировать ... я не
> получил ни одного писльма по поводу данной проблемы.
Не в курсе. Могу только порекоммендовать в будущем делать несложную, но 
обязательную (рекомендательную?) программу бета-тестирования (или альфа- для 
Дедала???) и направлять её тестерам.

> опишите (лучше с логом) порядок выших действий и проблему более детально
> ... т.е. что обновлялось и в каком порядке. Дело в том, что из сказанного
> вами выше я понял, что конфиги соответствующих модулей не были установлены
> из /usr/share/php/extconf в /etc/php/<mod>/php.d
Да. Я полагаю что это возникло при апдейте, но не при инсталле.

> это может произойти только в том случае, если был нарушен порядок
> установки новых версий пакетов в систему...
Да - делается достаточно регулярный dist-upgrade.
Есть два хоста - один был переведен на Сизиф с Мастера 2.2 примерно 
пол-года назад. 
Второй хост - на прошлой неделе поставлен с Compact-20031030
Проблема была на первом хосте, видимо там был выполнен dist-upgrade
Для второго хоста проблема не наблюдалась.
И логах первого хоста я факты апдейта не нашел (кстати - ?).
Хотя записи в syslog.conf для messages одинаковые для обеих хостов.
Вот лог второго хоста (grep php /var/log/syslog/messages*):
Nov  4 16:13:00 host2 rpm: php-common-1:4.3.4-alt0.cvs20030903 installed
Nov  4 16:13:00 host2 rpm: php-snmp-1:4.3.4-alt0.cvs20030830 installed
Nov  4 16:22:15 host2 rpm: php-1:4.3.4-alt0.cvs20030903 installed
Nov  4 16:22:16 host2 rpm: mod_php-1:4.3.4-alt0.cvs20030903 installed
Nov  4 16:22:17 host2 rpm: php-imap-1:4.3.4-alt0.cvs20030830 installed
Nov  5 12:31:48 host2 rpm: php-common-1:4.3.4-alt0.cvs20031101 installed
Nov  5 12:31:49 host2 rpm: php-common-1:4.3.4-alt0.cvs20030903 removed
Nov  5 12:31:49 host2 rpm: mod_php-1:4.3.4-alt0.cvs20031101 installed
Nov  5 12:31:49 host2 rpm: mod_php-1:4.3.4-alt0.cvs20030903 removed
Nov  5 12:31:49 host2 rpm: php-1:4.3.4-alt0.cvs20031101 installed
Nov  5 12:31:49 host2 rpm: php-1:4.3.4-alt0.cvs20030903 removed
Nov  5 12:31:49 host2 rpm: php-imap-1:4.3.4-alt0.cvs20031101 installed
Nov  5 12:31:49 host2 rpm: php-imap-1:4.3.4-alt0.cvs20030830 removed
Nov  5 12:31:49 host2 rpm: php-snmp-1:4.3.4-alt0.cvs20031101 installed
Nov  5 12:31:49 host2 rpm: php-snmp-1:4.3.4-alt0.cvs20030830 removed
Nov 10 13:21:40 host2 rpm: php-mysql-1:4.3.4-alt0.cvs20031101 installed
Nov 10 13:21:40 host2 rpm: php-dba-1:4.3.4-alt0.cvs20031101 installed
Nov 10 13:21:41 host2 rpm: php-gd2-1:4.3.4-alt0.cvs20031101 installed
Nov 10 13:21:42 host2 rpm: php-manual-ru-1:4.3.0-alt1 installed
Nov 10 13:21:42 host2 rpm: php-sockets-1:4.3.4-alt0.cvs20031101 installed

Тут видно, что с ним было всё гладко.

> сейчас я могу только посоветовать сделать --reinstall
Да я уже рученьками пофиксил, так что смысл?
Кстати, не совсем корректно, т.к. получил ошибку:
[10-Nov-2003 15:51:15] PHP Fatal error:  Call to undefined function:  iconv() 
in /var/www/html/squirrelmail/functions/i18n.php on line 77

[root@host1 php.d]# pwd
/etc/php/mod_php/php.d
[root@host1 php.d]# ls -1
curl.ini
dba.ini
fribidi.ini
imap.ini
mbstring.ini
mysql.ini
pcntl.ini
readline.ini
sockets.ini
xslt.ini

Ну и конечно же делал service httpd restart
Как пофиксить? Что я забыл включить?

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Leonid,

"LBS" == Leonid B Sysoletin wrote:

 LBS> Время должно быть либо на чтение доков и changelog'ов, либо на тупое
 LBS> копание в доке.

Кому оно должно?

 >> >> Или это у нас (пользователе-разработчиков Сизифа) начинает
 >> >> вырабатываться снобизм: "кто не допёр, тот сам себе злобный буратина". 
 >> >> Если так, то предлагаю (1) ориентироваться на obfurscated c, perl, etc
 >> >> content guidelines и (2) заранее предупредить остальных, чтобы вовремя
 >> >> успели спрыгнуть.
 LBS> Это тут при чём?
 >> Да при том, что Ваша реплика воспринимается как "ты не удовлетворяешь мои
 >> требованиям к админу, ergo пошёл нафиг".

 LBS> То есть? Если админ лихорадочно тащит с сети все неопробованные
 LBS> новинки, то мне его и дальше крутым админом называть?

Я не называю себя крутым админом.  Также мне неизвестны люди, которые меня
так называют.  

Я - разработчик, причём достаточно хороший.  Мой рабочий инструмент -
Сизиф, в создании которого, в меру своих сил я участвую.

Ещё раз, для полной ясности - на починку у меня ушло менее 5 минут ранним
утром, когда внезапно ночные тесты моих студентов все дружно обломались.
Меня сначало удивило то, что формат конфигурационных файлов поменялся (таки
да - пропустил анонс), затем - то, что соответствующее изменение не
описано в затронутом месте конфигов, и окончательно ошарашило то, что по
Вашим словам чьё-то время кому-то должно.

Резюме.  Добавление одной строки комментария может избавить от многих
вопросов и затрат времени многих людей.  Если абстрактная чистота ("время
должно быть") важнее эффективности - вперёд.  Я, со своей стороны, тему
закрыл.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2531 bytes --]

В сообщении от Пн 10 Ноя 2003 16:29 Alexey Gladkov написал(a):
> On Mon, Nov 10, 2003 at 03:53:14PM +0200, Andrey Khavryuchenko wrote:
> > Я, Андрей Хаврюченко, выбрал Сизиф по собственной воле, находясь в
> > здравом уме и трезвой памяти.
> > И я не понимаю, почему Вы, Леонид, возлагаете на _человека_ задачи[1],
> > которые элементарно упрощаются добавлением 1 (одной) стороки комментария
> > в конфиг. Объясните?
>
> я могу попробовать ответить ... раз уж вы выбрали Сизиф (тем более
> находясь в здравом уме) должны понимать что это нестабильный репозиторий и
> все анонсы об изменениях приходят в пакетах приходят в этот список. 
Замечу: Алексей, не будьте таким категоричным; в основном изменения 
аннонсируются, но я не сочту это за абсолютное утверждение.

> Если
> вы по каким-либо причинам не можете читать этот список вам необходимо
Да, например я упоминал о таком случае.

> перед установкой пакета ознакомиться с его changelog`ом
Типовой сценарий обновления системы:
apt-get update
apt-get upgrade
при этом вываливается список пакетов различного размера.
Для ежедневных обновлений он сравнительно небольшой, но предположим что 5-10 
обновлений в среднем (5 для серверной конфигурации, 10 для рабочей станции)
Даже в таких случаях админ не напрягает себя чтением изменений в changelog-e.
Правильно это или нет я не комментирую, но по факту (по опыту) это так.
Если же обновлять систему раз в месяц, то наверное легко вообразить, сколько 
времени потребуется администратору на ознакомление с изменениями.

> в противном случае в не сможете нормально реагировать на изменения.
Да, к сожалению, на практике это так.
Я стараюсь читать изменения по ключевым пакетам, с которыми я работаю, и в 
часности php к ним не относится, я просто его использую по зависимостям 
других пакетов.
Например, squirremail пользователям нужен для чтения почты, а не для выяснения 
деталей обновления php. 
Я понятно выразился?

> Конфиг - это не место для подобных объяснений для людей которые по
> собственной воле не следят за изменениями в пакете и не хотят читать
> сопроводительную документацию.
Причины, по которым среднестатистический администратор не в состоянии 
проверять изменения в обновлениях, я описал выше.
Добавлю, что упоминание в конфиге на файл php-packaging.readme мне очень 
способствовало локализации проблемы и её наискорейшему решению.
А теперь у меня к вам просьба - прочтите вопрос Андрея Хаврюченко в начале 
данного сообщения и напишите на него ответ ;)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: php: new config files structure???

[Leonid B. Sysoletin]

В сообщении от 10 Ноябрь 2003 18:00 Andrey Khavryuchenko написал(a):
> Ещё раз, для полной ясности - на починку у меня ушло менее 5 минут ранним
> утром, когда внезапно ночные тесты моих студентов все дружно обломались.
> Меня сначало удивило то, что формат конфигурационных файлов поменялся (таки
> да - пропустил анонс), затем - то, что соответствующее изменение не
> описано в затронутом месте конфигов, и окончательно ошарашило то, что по
> Вашим словам чьё-то время кому-то должно.

Ещё раз. Для полной ясности.
Если ставите апдейты, то, для вашего же блага, читайте его changelog.
А конфиги - это не место для помещения документации. Или место? Так давайте 
туда _всю_ документацию поместим, а?

> Резюме.  Добавление одной строки комментария может избавить от многих
> вопросов и затрат времени многих людей.  Если абстрактная чистота ("время
> должно быть") важнее эффективности - вперёд.  Я, со своей стороны, тему
> закрыл.

Клёво. Творческих узбеков.

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru, webmaster@bdo.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]
[Team Я люблю свою фортунку] [Team Фортунка в переписку не вступает]

boss, n:
	According to the Oxford English Dictionary, in the Middle Ages the
	words "boss" and "botch" were largely synonymous, except that boss,
	in addition to meaning "a supervisor of workers" also meant "an
	ornamental stud."

Re: [sisyphus] Re: php: new config files structure???

[Alexey Gladkov]

На мой взгляд пора закончить этот оффтопик... прошу всех кто хочет
продолжить эту тему писать приватом... ну или в talk-room...

---
Rgrds, legion

Re: [sisyphus] Re: php: new config files structure???

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 880 bytes --]

В сообщении от Пн 10 Ноя 2003 17:05 Leonid B. Sysoletin написал(a):

> Ещё раз. Для полной ясности.
> Если ставите апдейты, то, для вашего же блага, читайте его changelog.
> А конфиги - это не место для помещения документации. Или место? 
> Так давайте туда _всю_ документацию поместим, а?
Не впадайте в крайности, уважаемый!
Нигде речь не шла об вставке документации, но делать конфиги 
a-la MS Registry, IMHO, тоже не нужно.
В часности для php.ini предусмотрены контекстные комментарии, и я полагаю что 
вам должно быть понятно, зачем они там нужны.
Вы в Вашем утверждении ассоциируете комментарии и подсказки с документацией.
А это - некорректно.
Я согласен с Вами, ChangeLog читать надо, но по собственному опыту это 
относится к Best Practice, которая и есть Best, потому что не у всех.

DIXI, т.е. "замяли тему" :)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: php: new config files structure???

[Victor Forsyuk]

On Mon, Nov 10, 2003 at 06:05:24PM +0300, Leonid B. Sysoletin wrote:
> В сообщении от 10 Ноябрь 2003 18:00 Andrey Khavryuchenko написал(a):
> > Ещё раз, для полной ясности - на починку у меня ушло менее 5 минут ранним
> > утром, когда внезапно ночные тесты моих студентов все дружно обломались.
> > Меня сначало удивило то, что формат конфигурационных файлов поменялся (таки
> > да - пропустил анонс), затем - то, что соответствующее изменение не
> > описано в затронутом месте конфигов, и окончательно ошарашило то, что по
> > Вашим словам чьё-то время кому-то должно.
> 
> Ещё раз. Для полной ясности.
> Если ставите апдейты, то, для вашего же блага, читайте его changelog.
> А конфиги - это не место для помещения документации. Или место? Так давайте 

Место.

> туда _всю_ документацию поместим, а?

Rationale? А вот URL полной документации - хороший стиль.

 
> > Резюме.  Добавление одной строки комментария может избавить от многих
> > вопросов и затрат времени многих людей.  Если абстрактная чистота ("время
> > должно быть") важнее эффективности - вперёд.  Я, со своей стороны, тему
> > закрыл.
> 
> Клёво. Творческих узбеков.

????

[sisyphus] Re: php: new config files structure???

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

On Mon, Nov 10, 2003 at 04:47:24PM +0200, Nick Fedchik wrote:
> [10-Nov-2003 15:51:15] PHP Fatal error:  Call to undefined function:  iconv() 

Когда-то был php-iconv...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: php: new config files structure???

[Michael Shigorin]

On Mon, Nov 10, 2003 at 01:54:39PM +0200, Andrey Khavryuchenko wrote:
> А то, что банально может не оказаться времени на чтение всего списка?  

Бывает.

> Этот случай, конечно, чинится за 5 минут, не глядя в доку, но
> всё равно, остаётся вопрос "А нахрена, собственно?"

Андрюш, остынь.  Это сродни переезду по инитскриптам.  Больно, но
оно того стоит in the long run.

Хочешь пинать -- пинай меня, это я legion@ подбил к такому
переезду.  ЧТобы не плясать с echo >> и subst с каждым пакетиком
php-*.

> Или это у нас (пользователе-разработчиков Сизифа) начинает
> вырабатываться снобизм: "кто не допёр, тот сам себе злобный
> буратина".

Та ни.  У меня обратное впечатление -- все понимают, чем это
грозило бы.

> IMO проще и эффективнее вставить ещё одну строку в дефолный
> /etc/php/<mod>/php.ini со ссылкой на соответствующий
> /usr/share/doc/php*/*, чем ставить пальцЫ.

Ну где тут пальцы?

> _Мне_ прозрачная работоспособность важнее чем.

Помоги майнтейнеру.  Он честно сделал все, что мог.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: php: new config files structure???

[Michael Shigorin]

On Mon, Nov 10, 2003 at 03:53:14PM +0200, Andrey Khavryuchenko wrote:
> элементарно упрощаются добавлением 1 (одной) стороки
> комментария в конфиг.  Объясните?  Или мне прислать патч?

Присылай, чего грозишься.  Или уже в BTS? :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: php: new config files structure???

[Michael Shigorin]

On Mon, Nov 10, 2003 at 05:00:18PM +0200, Andrey Khavryuchenko wrote:
> Меня сначало удивило то, что формат конфигурационных файлов
> поменялся (таки да - пропустил анонс), затем - то, что
> соответствующее изменение не описано в затронутом месте
> конфигов

В таком случае я уже привык смотреть в changelog пакета.  Честно
говоря -- в гораздо более первую очередь, чме в конфиг или
%_docdir.

> Резюме.  Добавление одной строки комментария может избавить от
> многих вопросов и затрат времени многих людей.

Озвучь пример; заодно можешь сделать его _хорошим_ примером :-)

> Если абстрактная чистота ("время должно быть") важнее
> эффективности - вперёд.

Тю.  Откуда ты это выкопал.

Народ, расслабьтесь.  Недовольные действительно сами нажали
<enter>, а катить бочку на коллегу-майнтейнера -- последнее дело.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: php: new config files structure???

[Alexander Bokovoy]

On Mon, Nov 10, 2003 at 07:39:42PM +0200, Michael Shigorin wrote:
> On Mon, Nov 10, 2003 at 01:54:39PM +0200, Andrey Khavryuchenko wrote:
> > А то, что банально может не оказаться времени на чтение всего списка?  
> 
> Бывает.
> 
> > Этот случай, конечно, чинится за 5 минут, не глядя в доку, но
> > всё равно, остаётся вопрос "А нахрена, собственно?"
> 
> Андрюш, остынь.  Это сродни переезду по инитскриптам.  Больно, но
> оно того стоит in the long run.
> 
> Хочешь пинать -- пинай меня, это я legion@ подбил к такому
> переезду.  ЧТобы не плясать с echo >> и subst с каждым пакетиком
> php-*.
:) Гы. А как я его грозил бойкотировать, если не будет сделано это
*правильно*. В результате, у нас сейчас лучшая система подключения модулей
к PHP по сравнению со всеми дистрибутивами и уж тем более, с upstream.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[sisyphus] Re: php: new config files structure???

[Andrey Khavryuchenko]

Michael,

"MS" == Michael Shigorin wrote:

 MS> On Mon, Nov 10, 2003 at 03:53:14PM +0200, Andrey Khavryuchenko wrote:
 >> элементарно упрощаются добавлением 1 (одной) стороки
 >> комментария в конфиг.  Объясните?  Или мне прислать патч?

 MS> Присылай, чего грозишься.  Или уже в BTS? :)

http://bugzilla.altlinux.ru/show_bug.cgi?id=3253
http://bugzilla.altlinux.ru/show_bug.cgi?id=3254

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

[sisyphus] php: iconv

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 859 bytes --]

В сообщении от Пн 10 Ноя 2003 19:36 Michael Shigorin написал(a):
> On Mon, Nov 10, 2003 at 04:47:24PM +0200, Nick Fedchik wrote:
> > [10-Nov-2003 15:51:15] PHP Fatal error:  Call to undefined function: 
> > iconv()
>
> Когда-то был php-iconv...
Мне по данному вопросу мнения различные высказывались.
Мнение 1:
...Для поддержки функций iconv надо выкачать библиотеку libiconv с 
http://clisp.cons.org/~haible/packages-libiconv.html
Скомпилять php с поддержкой этой библиотеки ./configure --with-iconv (указать 
другие опции)

Мнение 2:
...iconv живет в glibc-core

php.spec:
Obsoletes: php-iconv ...
...
%configure \
...
--with-iconv \
...

Sources:
/php-4.3.4-20031101/ext/iconv
Значит еще к этому iconv живет в исходниках php? :)

Похоже что всё должно быть гут... :-/
Или я что-то не так, или где?

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: php: new config files structu???

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Mon, Nov 10, 2003 at 07:44:09PM +0200, Michael Shigorin wrote:

 > Народ, расслабьтесь.  Недовольные действительно сами нажали
 > <enter>, а катить бочку на коллегу-майнтейнера -- последнее дело.

Михаил, катить бочку, конечно, не надо, однако практика явных _недоделок_
в пакетах, которые создают _неоправданые_ проблемы для администратора при
обновлениях не есть Right Thing (tm).

Точно так же, как нашумевшая некоторое время назад проблема с неработой
su просле обновления (которая могла быть решена ментейнером элементарным
указанием более разумных установок по-умолчанию).

Конечно, мейнтейнер никому ничего не обязан, однако не соглашаться с тем,
что такой подход это _бага_, которую стоит либо _исправить_, либо
отказаться от её исправления (а не её существования), желательно
мотивировано (хотя бы на уровне "мне это пофиг, клал я на пользователей,
у меня всё работает, хотите пофиксить присылайте патчи"), что будет по
крайней мере более честным, чем не признавать наличие проблемы.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] php: iconv

[Alexander Bokovoy]

On Tue, Nov 11, 2003 at 10:05:41AM +0200, Nick Fedchik wrote:
Content-Description: signed data
> В сообщении от Пн 10 Ноя 2003 19:36 Michael Shigorin написал(a):
> > On Mon, Nov 10, 2003 at 04:47:24PM +0200, Nick Fedchik wrote:
> > > [10-Nov-2003 15:51:15] PHP Fatal error:  Call to undefined function: 
> > > iconv()
> >
> > Когда-то был php-iconv...
> Мне по данному вопросу мнения различные высказывались.
> Мнение 1:
> ...Для поддержки функций iconv надо выкачать библиотеку libiconv с 
> http://clisp.cons.org/~haible/packages-libiconv.html
> Скомпилять php с поддержкой этой библиотеки ./configure --with-iconv (указать 
> другие опции)
Не надо собирать с внешним libiconv. Это просто не для glibc-систем.

> 
> Мнение 2:
> ...iconv живет в glibc-core
> 
> php.spec:
> Obsoletes: php-iconv ...
> ...
> %configure \
> ...
> --with-iconv \
> ...
> 
> Sources:
> /php-4.3.4-20031101/ext/iconv
> Значит еще к этому iconv живет в исходниках php? :)
Ну живет и что? Просто PHP предназначен для работы на гораздо большем
количестве систем, чем просто glibc-based. В нашем случае поддержка iconv
должна быть встроенной в основной php.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [sisyphus] [OFFTOPIC] php: iconv

[Епифанов Сергей]

В сообщении от 11 Ноябрь 2003 11:26 Alexander Bokovoy написал:
> On Tue, Nov 11, 2003 at 10:05:41AM +0200, Nick Fedchik wrote:
> Content-Description: signed data
>
> > В сообщении от Пн 10 Ноя 2003 19:36 Michael Shigorin написал(a):
> > > On Mon, Nov 10, 2003 at 04:47:24PM +0200, Nick Fedchik wrote:
> > > > [10-Nov-2003 15:51:15] PHP Fatal error:  Call to undefined
> > > > function: iconv()
> > >
> > > Когда-то был php-iconv...
> >
> > Мне по данному вопросу мнения различные высказывались

На этом месте письмо оборвалось...

Скажите, это у меня иногда так режется письмо или это это делает mailman, 
smtp-сервер, etc?

-- 
С уважением, Епифанов Сергей

[sisyphus] Re: [OFFTOPIC] php: iconv

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Tue, 11 Nov 2003 11:54:02 +0300
Епифанов Сергей <serpiph@entek.ru> wrote:

> В сообщении от 11 Ноябрь 2003 11:26 Alexander Bokovoy написал:
> > On Tue, Nov 11, 2003 at 10:05:41AM +0200, Nick Fedchik wrote:
> > Content-Description: signed data
> >
> > > В сообщении от Пн 10 Ноя 2003 19:36 Michael Shigorin
> > > написал(a):
> > > > On Mon, Nov 10, 2003 at 04:47:24PM +0200, Nick Fedchik
> > > > wrote:
> > > > > [10-Nov-2003 15:51:15] PHP Fatal error:  Call to
> > > > > undefined function: iconv()
> > > >
> > > > Когда-то был php-iconv...
> > >
> > > Мне по данному вопросу мнения различные высказывались
> 
> На этом месте письмо оборвалось...
> 
> Скажите, это у меня иногда так режется письмо или это это
> делает mailman, smtp-сервер, etc?

Не знаю, у меня тоже не прочиталось.

sylpheed-0.9.6-alt1

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] php: iconv

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 706 bytes --]

В сообщении от Вт 11 Ноя 2003 10:26 Alexander Bokovoy написал(a):
> > Sources:
> > /php-4.3.4-20031101/ext/iconv
> > Значит еще к этому iconv живет в исходниках php? :)
> Ну живет и что? 
Ничего. Не работает ведь...

> Просто PHP предназначен для работы на гораздо большем
> количестве систем, чем просто glibc-based. 
Этого никто не отрицает.

> В нашем случае поддержка iconv
> должна быть встроенной в основной php.
Должна, и флаг для конфигурации в спеке даже выставлен.
Но - скрипты вызов не делают, судя по ошибке.
А какой php "не основной"?

Я свою проблему решил - отключил использование iconv в squirrelmail.
Пока что приемлемо работает.

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] бочки для мейнтейнеров нестабильного репозитория

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 976 bytes --]

В сообщении от Вт 11 Ноя 2003 10:21 Денис Смирнов написал(a):
>  > Народ, расслабьтесь.  Недовольные действительно сами нажали
>  > <enter>, а катить бочку на коллегу-майнтейнера -- последнее дело.
Миша, а с чем бочка то? ;)
Например, недовольный был я. К кому мне в возникшей ситуации надо было 
направлять багрепорт? Ну не к Папе Римскому же...
Так что я считаю твое утверждение "последнее дело" неоправданным.

> Михаил, катить бочку, конечно, не надо, однако практика явных _недоделок_
> в пакетах, которые создают _неоправданые_ проблемы для администратора при
> обновлениях не есть Right Thing (tm).
Почему же практика? Со всеми случаются неприятности, но не надо такие ситуации 
использвать для обвинений в чей-то адрес.

Я считаю что нужно стремиться решать проблему, а не искать виновных, по 
крайней мере до того момента, пока проблема не будет решена.
В контексте Сизифа это есть нормально, на мой взгляд.

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] php: iconv

[Alexander Bokovoy]

On Tue, Nov 11, 2003 at 12:29:23PM +0200, Nick Fedchik wrote:
Content-Description: signed data
> В сообщении от Вт 11 Ноя 2003 10:26 Alexander Bokovoy написал(a):
> > > Sources:
> > > /php-4.3.4-20031101/ext/iconv
> > > Значит еще к этому iconv живет в исходниках php? :)
> > Ну живет и что? 
> Ничего. Не работает ведь...
Это исходники PHP. Вполне естественно, что исходники связки с iconv живут
в исходниках PHP.

> > Просто PHP предназначен для работы на гораздо большем
> > количестве систем, чем просто glibc-based. 
> Этого никто не отрицает.
> 
> > В нашем случае поддержка iconv
> > должна быть встроенной в основной php.
> Должна, и флаг для конфигурации в спеке даже выставлен.
> Но - скрипты вызов не делают, судя по ошибке.
> А какой php "не основной"?
Не знаю, какой "не основной". У нас есть libphpcommon.so, в котором
содержится общие для всех SAPI функции. "Встроенный" означает входящий в
libphpcommon.so. Во всяком случае, туда оно входит:

         U iconv
         U iconv_close
00127be0 D iconv_functions
0012d4f8 B iconv_globals
00127c20 D iconv_module_entry
         U iconv_open
000e14a0 T php_if_iconv
000e1920 T zif_iconv_get_encoding
000e17d0 T zif_iconv_set_encoding
000e1570 T zif_ob_iconv_handler
000e10b0 T zm_info_miconv
000e1080 T zm_shutdown_miconv
000e0fd0 T zm_startup_miconv

Далее, ставлю php, php-common и получаю в ответ на простую программу 

<?php
phpinfo();
?>

Что поддержка iconv присутствует:

iconv

iconv support => enabled
iconv implementation => glibc
iconv library version => 2.2.6

Directive => Local Value => Master Value
iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1

> Я свою проблему решил - отключил использование iconv в squirrelmail.
> Пока что приемлемо работает.
Вот банальный пример его работоспособности:
$ cat test.php 
<?php
$test = 'Iconv форева';

var_dump(iconv("CP1251", "UTF-8", $test));
?>

$ php test.php
string(18) "Iconv форева"

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [sisyphus] php: iconv

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2721 bytes --]

В сообщении от Вт 11 Ноя 2003 12:57 Alexander Bokovoy написал(a):
> Вот банальный пример его работоспособности:
> $ cat test.php
> <?php
> $test = 'Iconv форева';
>> var_dump(iconv("CP1251", "UTF-8", $test));
> ?>
>> $ php test.php
> string(18) "Iconv форева"

Использую хост1 (был переведен на Сизиф с Мастера 2.2 примерно 
пол-года назад, неудачный апдейт php)
Ок, делаю у себя:

cat test-iconv.php
<?php
$test = 'Iconv Привет';
var_dump(iconv("KOI8-R", "CP1251", $test));
?>
[root@vatra html]# php test-iconv.php
string(12) "Iconv оПХБЕР"
Гут? Полагаю что да.

Далее:
http://host1/test-iconv.php

Fatal error: Call to undefined function: iconv() in 
/var/www/html/test-iconv.php on line 3

Наглядная демонстрация проблемы?


Приложение 1: Фрагменты вывода вызова phpinfo() 
Configure Command 	 './configure' '--build=i586-alt-linux' 
'--host=i586-alt-linux' '--prefix=/usr' '--exec-prefix=/usr' 
...
'--enable-calendar' '--enable-bcmath' '--enable-ctype' '--with-iconv' 
...
Configuration File (php.ini) Path 	/etc/php/mod_php/php.ini
PHP API 	20020918
PHP Extension 	20020429 

Приложение 2: Версии установленных пакетов
# rpm -q -a | grep php
mod_php-4.3.4-alt0.cvs20031101
php-common-4.3.4-alt0.cvs20031101
php-imap-4.3.4-alt0.cvs20031101
php-xslt-4.3.4-alt0.cvs20031101
php-mhash-4.3.0-alt0.cvs20030124
php-sockets-4.3.4-alt0.cvs20031101
php-mmcache-2.4.4-alt1
php-curl-4.3.4-alt0.cvs20031101
php-readline-4.3.4-alt0.cvs20031101
php-4.3.4-alt0.cvs20031101
php-dba-4.3.4-alt0.cvs20031101
php-mysql-4.3.4-alt0.cvs20031101
php-snmp-4.3.4-alt0.cvs20031101
php-manual-ru-4.3.0-alt1
php-mcrypt-4.3.0-alt0.cvs20030124
php-devel-4.3.4-alt0.cvs20031101
php-openssl-4.3.4-alt0.cvs20031101
php-ldap-4.3.4-alt0.cvs20031101
php-pear-4.3.4-alt0.cvs20031101
php-pcntl-4.3.4-alt0.cvs20031101
phpMyAdmin-2.5.4-alt1
php-fribidi-4.3.4-alt0.cvs20031101
php-mbstring-4.3.4-alt0.cvs20031101


Приложение 3: Связи динамических библиотек для модуля libphp4.so
ldd libphp4.so
        libphp4common.so => /usr/lib/libphp4common.so (0x4000f000)
        libc.so.6 => /lib/libc.so.6 (0x40141000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4025d000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4028f000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402a4000)
        libmm.so.1 => /usr/lib/libmm.so.1 (0x402c3000)
        libz.so.1 => /lib/libz.so.1 (0x402c7000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402d6000)
        libm.so.6 => /lib/libm.so.6 (0x402e9000)
        libdl.so.2 => /lib/libdl.so.2 (0x4030c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] php: iconv

[Alexey Gladkov]

On Tue, Nov 11, 2003 at 02:06:14PM +0200, Nick Fedchik wrote:
> Использую хост1 (был переведен на Сизиф с Мастера 2.2 примерно 
> пол-года назад, неудачный апдейт php)
> Ок, делаю у себя:
> 
> cat test-iconv.php
> <?php
> $test = 'Iconv Привет';
> var_dump(iconv("KOI8-R", "CP1251", $test));
> ?>
> [root@vatra html]# php test-iconv.php
> string(12) "Iconv оПХБЕР"
> Гут? Полагаю что да.
> 
> Далее:
> http://host1/test-iconv.php
> 
> Fatal error: Call to undefined function: iconv() in 
> /var/www/html/test-iconv.php on line 3
> 
> Наглядная демонстрация проблемы?
>

Да, вполне наглядная ... сейчас разбераюсь

---
Rgrds, legion

Re: [sisyphus] php: iconv

[Alexander Bokovoy]

On Tue, Nov 11, 2003 at 02:06:14PM +0200, Nick Fedchik wrote:
Content-Description: signed data
> В сообщении от Вт 11 Ноя 2003 12:57 Alexander Bokovoy написал(a):
> > Вот банальный пример его работоспособности:
> > $ cat test.php
> > <?php
> > $test = 'Iconv форева';
> >> var_dump(iconv("CP1251", "UTF-8", $test));
> > ?>
> >> $ php test.php
> > string(18) "Iconv форева"
> 
> Использую хост1 (был переведен на Сизиф с Мастера 2.2 примерно 
> пол-года назад, неудачный апдейт php)
> Ок, делаю у себя:
> 
> cat test-iconv.php
> <?php
> $test = 'Iconv Привет';
> var_dump(iconv("KOI8-R", "CP1251", $test));
> ?>
> [root@vatra html]# php test-iconv.php
> string(12) "Iconv оПХБЕР"
> Гут? Полагаю что да.
> 
> Далее:
> http://host1/test-iconv.php
> 
> Fatal error: Call to undefined function: iconv() in 
> /var/www/html/test-iconv.php on line 3
> 
> Наглядная демонстрация проблемы?
Да. Ее -- в bug report на bugzilla.altlinux.ru и пусть legion думает над
разницей в поведении.


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [sisyphus] php: iconv

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 588 bytes --]

В сообщении от Вт 11 Ноя 2003 14:26 Alexey Gladkov написал(a):
> On Tue, Nov 11, 2003 at 02:06:14PM +0200, Nick Fedchik wrote:
> > Использую хост1 (был переведен на Сизиф с Мастера 2.2 примерно
> > пол-года назад, неудачный апдейт php)
> > Fatal error: Call to undefined function: iconv() in
> > /var/www/html/test-iconv.php on line 3
> > Наглядная демонстрация проблемы?
> Да, вполне наглядная ... сейчас разбераюсь
Это из-за некорректной конфигурации mod_php?

Полагаю что уже нет необходимости оформлять 
отчёт в bugzilla? ;)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] php: iconv

[Alexey Gladkov]

On Tue, Nov 11, 2003 at 02:46:00PM +0200, Nick Fedchik wrote:
> Это из-за некорректной конфигурации mod_php?
> 
> Полагаю что уже нет необходимости оформлять 
> отчёт в bugzilla? ;)
> 

Да, mod_php не корректно собран ... в нем вообще поддердка iconv не
сделана. 

---
Rgrds, legion

Re: [sisyphus] php: iconv

[Nick Fedchik]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 504 bytes --]

В сообщении от Вт 11 Ноя 2003 15:19 Alexey Gladkov написал(a):
> On Tue, Nov 11, 2003 at 02:46:00PM +0200, Nick Fedchik wrote:
> > Это из-за некорректной конфигурации mod_php?
> > Полагаю что уже нет необходимости оформлять
> > отчёт в bugzilla? ;)
>
> Да, mod_php не корректно собран ... в нем вообще поддержка iconv не
> сделана.
Ну вот и чудненько. :)
Значит не зря столько постов было.
Надеюсь увидеть исправленную версию в ближайшее время.

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] [POLICY] Re: php: new config files structu???

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Tue, Nov 11, 2003 at 11:21:05AM +0300, Денис Смирнов wrote:
> Точно так же, как нашумевшая некоторое время назад проблема с
> неработой su просле обновления (которая могла быть решена
> ментейнером элементарным указанием более разумных установок
> по-умолчанию).

Э, то другой случай.

Здесь имеем дело с проблемой, которая предвиделась и в меру
возможностей решалась, а там -- с принятием решения за
администратора, причем в неочевидном и недокументированном виде.

Вот последнее и есть The Wrong Thing.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] [POLICY] Re: php: new config files structu???

[Sergey Degtyaryov]

Michael Shigorin пишет:
> On Tue, Nov 11, 2003 at 11:21:05AM +0300, Денис Смирнов wrote:
> 
>>Точно так же, как нашумевшая некоторое время назад проблема с
>>неработой su просле обновления (которая могла быть решена
>>ментейнером элементарным указанием более разумных установок
>>по-умолчанию).
> 
> 
> Э, то другой случай.
> 
> Здесь имеем дело с проблемой, которая предвиделась и в меру
> возможностей решалась, а там -- с принятием решения за
> администратора, причем в неочевидном и недокументированном виде.
> 
> Вот последнее и есть The Wrong Thing.

Мне кажется вообще разумной идея собирать конфиги в пакеты.

ppp-2.4.1.20030513-alt2
ppp-dialup-server-1.0 с зависимостью на пакет выше.

php-4.3.0-blahblah
php-config-4.3.0-blahblah

и т.д.

--
Сергей Дегтярев

Re: [sisyphus] [POLICY] Re: php: new config files structu???

[Alexey Gladkov]

On Wed, Nov 12, 2003 at 12:44:26AM +0300, Sergey Degtyaryov wrote:
> Мне кажется вообще разумной идея собирать конфиги в пакеты.
> 
> ppp-2.4.1.20030513-alt2
> ppp-dialup-server-1.0 с зависимостью на пакет выше.
> 
> php-4.3.0-blahblah
> php-config-4.3.0-blahblah
> 
> и т.д.
> 

Нет. Это плохая идея ... 

---
Rgrds, legion

[sisyphus] Re: бочки для мейнтейнеров нестабильного репозитория

[Денис Смирнов]

On Tue, Nov 11, 2003 at 12:45:03PM +0200, Nick Fedchik wrote:

>> Михаил, катить бочку, конечно, не надо, однако практика явных _недоделок_
>> в пакетах, которые создают _неоправданые_ проблемы для администратора при
>> обновлениях не есть Right Thing (tm).
> Почему же практика?

Потому что это встречается достаточно часто.

> Со всеми случаются неприятности, но не надо такие ситуации 
> использвать для обвинений в чей-то адрес.

Разумеется. Обвинения вообще штука не конструктивная. Нужно просто
констатировать факт "произошло это, так лучше не делать, лучше делать так"
(что, собственно, я и увидел в этой эхе)

> Я считаю что нужно стремиться решать проблему, а не искать виновных, по 
> крайней мере до того момента, пока проблема не будет решена.
> В контексте Сизифа это есть нормально, на мой взгляд.

Разумеется нормально. Однако реакция Леонида на информацию об ошибке в
стиле близком к "ставят сизиф и надеятся на работоспособность только
ламеры" не есть полезная.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: [POLICY] php: new config files structu???

[Денис Смирнов]

On Tue, Nov 11, 2003 at 07:40:07PM +0200, Michael Shigorin wrote:

 >> Точно так же, как нашумевшая некоторое время назад проблема с
 >> неработой su просле обновления (которая могла быть решена
 >> ментейнером элементарным указанием более разумных установок
 >> по-умолчанию).
 > Э, то другой случай.
 > Здесь имеем дело с проблемой, которая предвиделась и в меру
 > возможностей решалась, а там -- с принятием решения за
 > администратора, причем в неочевидном и недокументированном виде.
 > Вот последнее и есть The Wrong Thing.

Wrong Thing любое изменение конфигурации системы при обновлении без
предупреждения пользователя. То есть если стояла одна версия софта и админ
её обновил (штатным методом, то есть apt-get), то он вправе рассчитывать
на то, что конфигурация системы не изменится, в случае же если это
невозможно, то установки по-умолчанию должны быть максимально близки к
тому, что было до обновления, а информацию об изменениях кроме как на
stderr админ должен получить на root@. Любое другое поведение системы при
обновлении является поводом повесить block bug в BTS.

Это всё IMHO, конечно, но мне кажется что только такое отношение к
обновлениям заметно облегчит жизнь администраторам.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: php: new config files structu???

[Michael Shigorin]

On Wed, Nov 12, 2003 at 05:05:37PM +0300, Денис Смирнов wrote:
> невозможно, то установки по-умолчанию должны быть максимально
> близки к тому, что было до обновления, а информацию об
> изменениях кроме как на stderr админ должен получить на root@.

Это подразумевает рабочий почтовик.  Т.е. уже серьезно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: php: new config files structu???

[Денис Смирнов]

On Wed, Nov 12, 2003 at 06:29:41PM +0200, Michael Shigorin wrote:

 >> невозможно, то установки по-умолчанию должны быть максимально
 >> близки к тому, что было до обновления, а информацию об
 >> изменениях кроме как на stderr админ должен получить на root@.
 > Это подразумевает рабочий почтовик.  Т.е. уже серьезно.

Есть другие предложения? Я ничего кроме stderr с дублированием на почтовик
не вижу.

К тому же ситуация, при которой обновление может блокировать работу
почтовика, является одной из той, опасность которых мейнтенерам хорошо бы
учитывать и стараться преодолеть. Хуже падения почтовика может быть только
падение sshd или проблемы с pam (не считая потерь данных, конечно).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: php: new config files structu???

[Michael Shigorin]

On Thu, Nov 13, 2003 at 04:28:27AM +0300, Денис Смирнов wrote:
>  >> невозможно, то установки по-умолчанию должны быть
>  >> максимально близки к тому, что было до обновления, а
>  >> информацию об изменениях кроме как на stderr админ должен
>  >> получить на root@.
>  > Это подразумевает рабочий почтовик.  Т.е. уже серьезно.
> Есть другие предложения? Я ничего кроме stderr с дублированием
> на почтовик не вижу.

Я только за (при условии почты _только_ с проблемами... но это
личное, а по-хорошему -- должно регулерироваться).

Сделаете?

> К тому же ситуация, при которой обновление может блокировать
> работу почтовика, является одной из той, опасность которых
> мейнтенерам хорошо бы учитывать и стараться преодолеть. Хуже
> падения почтовика может быть только падение sshd или проблемы с
> pam (не считая потерь данных, конечно).

Вот.  А тут добавляется еще одно требование его живости.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Надёжность Sisyphus

[Денис Смирнов]

On Thu, Nov 13, 2003 at 04:58:57PM +0200, Michael Shigorin wrote:

 >>>> невозможно, то установки по-умолчанию должны быть
 >>>> максимально близки к тому, что было до обновления, а
 >>>> информацию об изменениях кроме как на stderr админ должен
 >>>> получить на root@.
 >>> Это подразумевает рабочий почтовик.  Т.е. уже серьезно.
 >> Есть другие предложения? Я ничего кроме stderr с дублированием
 >> на почтовик не вижу.
 > Я только за (при условии почты _только_ с проблемами... но это
 > личное, а по-хорошему -- должно регулерироваться).
 > Сделаете?

Хм. Кажется я нечётно сформулировал свою мысль. Попробую сначала.

Проблема: периодически попытки обновиться из сизифа приводят к
неработоспособности системы.

Задача: техническими и/или административными методами уменьшить
вероятность получения системным администратором по голове от руководства
и клиентов при попытке пбновиться.

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

Причины:
 - ошибки в upstream
   С этим борется каждый мантейнер как может, гарантированых решений быть
   не может. Улучшить ситуацию можно:
   1. автоматическими тестированиями;
      
      как реализовать это на практике в общем виде я себе представляю
      слабо, однако для таких продуктов как PHP вполне можно реализовать
      набор тестов (хотя бы анализ того, что возвращает phpinfo() ).
   
   2. тестированием в условиях приближеных к боевым в течении нескольких
      дней группой из тех, для кого развитие этих пакетов является важным,
      и кто, возможно, своей головой будет отвечать за работоспособность и
      функциональность сервисов на базе данного пакета, используемых в его
      организации.

      уточнение: тестирование не _всех_ пакетов, а только тех, которые
      персонально для него важны.

      как реализовать: разделить сизиф на два уровня, новые пакеты всегда
      добавляются в один из уровней, если за неделю никаких изменений в
      нём не было (или на него не висит в BTS block-bug'ов), то
      автоматически переносить его в основной репозитарий. Вся эта работа
      должна выполняться автоматически, без участия человека (что снизит
      нагрузку на incominger'ов заодно).

      при этом иметь список людей (привязаный к каждому пакету)
      заинтересованых в том, чтобы отслеживать развитие данного
      конкретного пакета, речь идёт о людях _не обязательно_ являющихся
      членами Team.

      соответственно это даст возможностям людям принимать решения,
      насколько они готовы быть тестерами (то есть тестировать совсем
      сырые версии пакетов, или уже хорошо протестированые).

 - ошибки в пакетах
   1. тестирование вроде приведённого выше;
   2. продуманое полиси, в котором будут перечислены вещи, на которые
      важно обращать внимание.

      собственно мои мысли на тему "при обновлении не должна меняться
      конфигурация", "если при обновлении меняется конфигурация, это повод
      срочно проинформировать админа, да ещё и так, чтобы он эту
      информацию потерять лишь с большим трудом мог", "при обновлении
      нельзя вносить изменения, которые могут блокировать удалённый доступ
      администратора к серверу" (это я всё pam вспоминаю), "средства
      коммуникации, журналирования, авторизации должны тестироваться особенно
      тщательно, и нарушение их работы недопустимо даже в Sisyphus" это
      исключительно мысли, которые, IMHO, имеет смысл в развёрнутом виде
      иметь в таком полиси (рекомендательно-объяснительного характера, ибо
      проверять каждый пакет на соответствие _перед_ добавлением в сизиф
      нереально ни для кого, кроме самого мантейнера).

      поэтому реализовать техническими методами то же информирование я не
      могу -- для этого мне надо добавить это во все пакеты, которые этого
      требуют.
   
 >> К тому же ситуация, при которой обновление может блокировать
 >> работу почтовика, является одной из той, опасность которых
 >> мейнтенерам хорошо бы учитывать и стараться преодолеть. Хуже
 >> падения почтовика может быть только падение sshd или проблемы с
 >> pam (не считая потерь данных, конечно).
 > Вот.  А тут добавляется еще одно требование его живости.

Сейчас эта информация просто теряется. Я же предлагаю её в бОльшей части
(заметно большей чем 99% случаев) давать возможность изучить
администратором. Ситуации, когда после обновления почтовик умирает так,
что даже его очередь гибнет, насколько мне известно, пока не встречались
(и слава богу).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] [POLICY] Re: Надёжность Sisyphus

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 4507 bytes --]

On Thu, Nov 13, 2003 at 09:00:22PM +0300, Денис Смирнов wrote:
> Обоснование: обновление из сизифа часто является вынужденым,
> даже если человек и не хочет принимать активного участия в
> разработке, по таким причинам, как отсутствие багфиксов к
> Мастеру, за исключением security.

Ммм... в таком случае может быть более осмысленно поддерживать
локальный репозиторий бэкпортов.  У меня в некоей форме такое
водится, по крайней мере leafnode и apache на alm2.2-системы
попадают именно так.

Если критичность * общесть проблемы превышает некий субъективный
порог -- может быть оправданно рекомендовать (org@?) включение
таких пакетов в updates после проверки.

> Причины:
>  - ошибки в upstream

Есть updates, которые errata.  Для критичных ошибок они могут
выпускаться.

>    С этим борется каждый мантейнер как может, гарантированых
>    решений быть не может. Улучшить ситуацию можно:
>    1. автоматическими тестированиями;
>       как реализовать это на практике в общем виде я себе
>       представляю слабо, однако для таких продуктов как PHP
>       вполне можно реализовать набор тестов (хотя бы анализ
>       того, что возвращает phpinfo() ).

Анализ по каким критериям?

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

Так без него критичность не определяется в любом случае.

>       при этом иметь список людей (привязаный к каждому пакету)
>       заинтересованых в том, чтобы отслеживать развитие данного
>       конкретного пакета, речь идёт о людях _не обязательно_
>       являющихся членами Team.

Ну так это участники BTS.  Это уже имеем.

>  - ошибки в пакетах
>    1. тестирование вроде приведённого выше;
>    2. продуманое полиси, в котором будут перечислены вещи, на
>       которые важно обращать внимание.

Ммм... боюсь, обобщить тестирование -- проблема еще та, судя по
количеству живой силы на этой задаче у поставщиков коммерческого
ПО.

>       собственно мои мысли на тему "при обновлении не должна
>       меняться конфигурация",

Зависит.  Иногда известно, что с имеющейся конфигурацией новый
код попросту не взлетит.

Т.к. в sisyphus изменения между большими ветками _могут_ быть и
бывают, то приходим к необходимости их отслеживать.  Т.к. это
трудно, то выход для тех, кому приходится пользовать sisyphus
вместо master видится таким:

- реализация механизма нотификации при поступлении новых пакетов,
  который позволил бы разделять изменения по степени масштабности
  (критичности, опасности).
  
  Примерно так уже сделано в Debian; у нас хотелось бы вырулить
  на то, информацию о чем можно получить той же почтой и
  отфильтровать по порогу, причем в идеале -- иметь возможность
  подвесить туда же робота (доступного в дистрибутиве), который
  может, глядя на подпись и некоторые иные критерии (тот же порог
  важности) -- дернуть rsync и/или apt и/или /bin/mail.

>       "если при обновлении меняется конфигурация, это повод
>       срочно проинформировать админа, да ещё и так, чтобы он
>       эту информацию потерять лишь с большим трудом мог"

Ммм... *.rpmsave?

>       "при обновлении нельзя вносить изменения, которые могут
>       блокировать удалённый доступ администратора к серверу"
>       (это я всё pam вспоминаю)

Полностью согласен.

>       "средства коммуникации, журналирования, авторизации
>       должны тестироваться особенно тщательно, и нарушение их
>       работы недопустимо даже в Sisyphus" это исключительно
>       мысли, которые, IMHO, имеет смысл в развёрнутом виде
>       иметь в таком полиси (рекомендательно-объяснительного
>       характера, ибо проверять каждый пакет на соответствие
>       _перед_ добавлением в сизиф нереально ни для кого, кроме
>       самого мантейнера).

Проблема в том, что люди, которые отвечают за базовые средства
удаленного доступа и контроля/смены привилегий -- a priori
полагаются более чем сведущими в вопросе.

Соответственно что делать с этим вопрсом -- непонятно.

>  >> К тому же ситуация, при которой обновление может блокировать
>  >> работу почтовика, является одной из той, опасность которых
>  > Вот.  А тут добавляется еще одно требование его живости.
> Сейчас эта информация просто теряется.

Лог?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: [POLICY] Надёжность Sisyphus

[Денис Смирнов]

On Thu, Nov 13, 2003 at 10:29:35PM +0200, Michael Shigorin wrote:

 >> Обоснование: обновление из сизифа часто является вынужденым,
 >> даже если человек и не хочет принимать активного участия в
 >> разработке, по таким причинам, как отсутствие багфиксов к
 >> Мастеру, за исключением security.
 > Ммм... в таком случае может быть более осмысленно поддерживать
 > локальный репозиторий бэкпортов.  У меня в некоей форме такое
 > водится, по крайней мере leafnode и apache на alm2.2-системы
 > попадают именно так.

Это решение со стороны администратора, на текущий момент единственное
и оптимальное. Я сейчас смотрю на проблему и методы её решения со стороны
разработки дистрибутива.

 > Если критичность * общесть проблемы превышает некий субъективный
 > порог -- может быть оправданно рекомендовать (org@?) включение
 > таких пакетов в updates после проверки.

Думаю что лучше всего если будет некий унифицированый подход. Чем меньше
исключений из правил, тем меньше шансов сделать что-нибудь не так.
 
 >> Причины:
 >>  - ошибки в upstream
 > Есть updates, которые errata.  Для критичных ошибок они могут
 > выпускаться.

Могут не значит выпускаются. Увы. Сейчас у админов нет выхода, кроме как
либо заниматься пересборкой пакетов из сизифа, либо обновляться до сизифа
во многих случаях.
 
 >>    С этим борется каждый мантейнер как может, гарантированых
 >>    решений быть не может. Улучшить ситуацию можно:
 >>    1. автоматическими тестированиями;
 >>       как реализовать это на практике в общем виде я себе
 >>       представляю слабо, однако для таких продуктов как PHP
 >>       вполне можно реализовать набор тестов (хотя бы анализ
 >>       того, что возвращает phpinfo() ).
 > Анализ по каким критериям?

Например соответствия тому, что утверждает PHP на предмет подключеных
модулей тому, что по этому поводу говорит rpm -qa | grep ^php-

Таких автоматических тестов придумать можно много. Вопрос только как может
выглядеть унифицированые средства для создания таких средств (пользователь
должен иметь возможность _быстро_ узнать о _наличии_ таких средств для
данного конкретного пакета, и по _каким параметрам_ это тестирование
выполняется).

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

Не понял реплику.
 
 > >       при этом иметь список людей (привязаный к каждому пакету)
 > >       заинтересованых в том, чтобы отслеживать развитие данного
 > >       конкретного пакета, речь идёт о людях _не обязательно_
 > >       являющихся членами Team.
 > Ну так это участники BTS.  Это уже имеем.

Они получают нотификации о каждом изменении пакета, каждом закрытии каждой
(не только ими выставленой) баги?
 
 >>  - ошибки в пакетах
 >>    1. тестирование вроде приведённого выше;
 >>    2. продуманое полиси, в котором будут перечислены вещи, на
 >>       которые важно обращать внимание.
 > Ммм... боюсь, обобщить тестирование -- проблема еще та, судя по
 > количеству живой силы на этой задаче у поставщиков коммерческого
 > ПО.

У поставщиков коммерческого ПО большие силы уходят на то, чтобы
тестировщик был заинтересован в тестировании. В случае free-software
community об этом заботиться смысла нет, достаточно позаботиться о том,
чтобы тем, кому это важно, это было сделать _легко_ (т.е. наличие
технических средств и документации).

То есть любой мантейнер-новичок должен знать о том, какие последствия
могут быть у каких серьёзных изменений. Тем более что даже зубры
ошибаются.
 
 >> собственно мои мысли на тему "при обновлении не должна
 >> меняться конфигурация",
 > Зависит.  Иногда известно, что с имеющейся конфигурацией новый
 > код попросту не взлетит.

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

 > Т.к. в sisyphus изменения между большими ветками _могут_ быть и
 > бывают, то приходим к необходимости их отслеживать.  Т.к. это
 > трудно, то выход для тех, кому приходится пользовать sisyphus
 > вместо master видится таким:
 
 > - реализация механизма нотификации при поступлении новых пакетов,
 >   который позволил бы разделять изменения по степени масштабности
 >   (критичности, опасности).

Ага, об этом я и говорю. Хотя как разделить эти изменения я не знаю, и,
IMHO, любые изменения которые изменяют поведение сервера после обновления
должны быть известны админу.
 
 >   Примерно так уже сделано в Debian; у нас хотелось бы вырулить
 >   на то, информацию о чем можно получить той же почтой и
 >   отфильтровать по порогу, причем в идеале -- иметь возможность
 >   подвесить туда же робота (доступного в дистрибутиве), который
 >   может, глядя на подпись и некоторые иные критерии (тот же порог
 >   важности) -- дернуть rsync и/или apt и/или /bin/mail.

Опа, мы кажется немного о разных вещах говорим :( Я говорил изначально
о нотификации изменений _после установки_, потом это уже спуталось с
другой моей идеей -- нотификацией заинтересованых лиц в выпуске нового
пакета.
 
 >>       "если при обновлении меняется конфигурация, это повод
 >>       срочно проинформировать админа, да ещё и так, чтобы он
 >>       эту информацию потерять лишь с большим трудом мог"
 > Ммм... *.rpmsave?

И это тоже. Однако информацию о том, что изменилось значение по-умолчанию
какой-то переменной оно содержать не будет, и если установочные скрипты не
могли это отследить, то тогда нужно информировать админа.
 
 > >       "средства коммуникации, журналирования, авторизации
 > >       должны тестироваться особенно тщательно, и нарушение их
 > >       работы недопустимо даже в Sisyphus" это исключительно
 > >       мысли, которые, IMHO, имеет смысл в развёрнутом виде
 > >       иметь в таком полиси (рекомендательно-объяснительного
 > >       характера, ибо проверять каждый пакет на соответствие
 > >       _перед_ добавлением в сизиф нереально ни для кого, кроме
 > >       самого мантейнера).
 > Проблема в том, что люди, которые отвечают за базовые средства
 > удаленного доступа и контроля/смены привилегий -- a priori
 > полагаются более чем сведущими в вопросе.
 
 > Соответственно что делать с этим вопрсом -- непонятно.

Только подразумевать то, что даже Величайшие Гуру являются всего лишь
живыми людьми и склонны хотя бы иногда ошибаться. Соответственно это
решается тем, что пакет должен полежать некоторое время в отстойнике и
быть провереным (и подписаным) ещё некотороым количеством людей, завсиящим
от уровня важности пакета.
 
 >>>> К тому же ситуация, при которой обновление может блокировать
 >>>> работу почтовика, является одной из той, опасность которых
 >>> Вот.  А тут добавляется еще одно требование его живости.
 >> Сейчас эта информация просто теряется.
 > Лог?

В каком логе была информация о изменении структуры конфига в PHP? Или о
изменении поведения su?

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: [POLICY] Надёжность Sisyphus

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 8596 bytes --]

On Fri, Nov 14, 2003 at 02:35:52AM +0300, Денис Смирнов wrote:
>  >> Обоснование: обновление из сизифа часто является
>  >> вынужденым, даже если человек и не хочет принимать
>  >> активного участия в разработке, по таким причинам, как
>  >> отсутствие багфиксов к Мастеру, за исключением security.
>  > Ммм... в таком случае может быть более осмысленно
>  > поддерживать локальный репозиторий бэкпортов.  У меня в
>  > некоей форме такое водится, по крайней мере leafnode и
>  > apache на alm2.2-системы попадают именно так.
> Это решение со стороны администратора, на текущий момент
> единственное и оптимальное.

Ну да.

> Я сейчас смотрю на проблему и методы её решения со стороны
> разработки дистрибутива.

А эта сторона станет возможной разве что при:

1) возникновении сильного и стабильного реплзитоиря таких
   бэкпортов;
2) принятия его "под крыло" alt.

>  > Если критичность * общесть проблемы превышает некий
>  > субъективный порог -- может быть оправданно рекомендовать
>  > (org@?) включение таких пакетов в updates после проверки.
> Думаю что лучше всего если будет некий унифицированый подход.
> Чем меньше исключений из правил, тем меньше шансов сделать
> что-нибудь не так.

Ох.  Да тут еще дожить до этих правил надо.

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

(у меня с этим проблемы)

>  >> Причины: - ошибки в upstream
>  > Есть updates, которые errata.  Для критичных ошибок они
>  > могут выпускаться.
> Могут не значит выпускаются. Увы.

Ессно.

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

Обычно срабатывает с этакой себе экспоненциально убывающей по
мере удаления сизифа от предыдущего релиза вероятностью.

Есть "объезды" в виде точечных включений в ~/.rpmmacros (вроде
%__subst), но уменьшение дублирования усилий может быть
осмысленным.  Может стать слишком тяжким бременем, правда.
(собирать бэкпорт nvidia/alsa для ядер из updates/Master/2.2 я
довольно давно обломался -- кажется, после очередной перемены по
kernel-headers-*, когда уверенность в пригодности результата
сильно снизилась, а проверить было уже почти негде)

> либо обновляться до сизифа во многих случаях.

Тестовая система.  Однозначно.

>  >>    1. автоматическими тестированиями;
[...]
>  >>       того, что возвращает phpinfo() ).
>  > Анализ по каким критериям?
> Например соответствия тому, что утверждает PHP на предмет подключеных
> модулей тому, что по этому поводу говорит rpm -qa | grep ^php-
> Таких автоматических тестов придумать можно много. Вопрос

А, вот как.  Это было бы неплохо (разве в данном конкретном
случае непонятен момент с подключением/неподключением модулей по
умолчанию: есть мысль, что некоторые из них могут быть упакованы
с тем, чтобы требовать _явного_ поворота рубильника).

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

(слишком мало вводных)

> Не понял реплику.

Без тестирования.  И без "того, кто отвечает головой".

>  > >       при этом иметь список людей (привязаный к каждому пакету)
>  > >       заинтересованых в том, чтобы отслеживать развитие данного
>  > >       конкретного пакета, речь идёт о людях _не обязательно_
>  > >       являющихся членами Team.
>  > Ну так это участники BTS.  Это уже имеем.
> Они получают нотификации о каждом изменении пакета

Нет.

> каждом закрытии каждой (не только ими выставленой) баги?

Можно подписаться на пакет IIRC.

>  >>  - ошибки в пакетах
>  >>    1. тестирование вроде приведённого выше;
>  >>    2. продуманое полиси, в котором будут перечислены вещи, на
>  >>       которые важно обращать внимание.
>  > Ммм... боюсь, обобщить тестирование -- проблема еще та, судя
>  > по количеству живой силы на этой задаче у поставщиков
>  > коммерческого ПО.
> У поставщиков коммерческого ПО большие силы уходят на то, чтобы
> тестировщик был заинтересован в тестировании. В случае
> free-software community об этом заботиться смысла нет,

Ой ли.

> достаточно позаботиться о том, чтобы тем, кому это важно, это
> было сделать _легко_ (т.е. наличие технических средств и
> документации).

Это заинтересованность в донесении результатов тестирования.
С точки зрения BTS -- одно и то же. :)

> Тем более что даже зубры ошибаются.

Ага... и при этом разлет щепок больше :-/

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

Ну, это "в идеале". (вспоминая раздумия над подобными сообщениями
при их составлении)

>  > - реализация механизма нотификации при поступлении новых
>  > пакетов, который позволил бы разделять изменения по степени
>  > масштабности (критичности, опасности).
> Ага, об этом я и говорю. Хотя как разделить эти изменения я не
> знаю, и, IMHO, любые изменения которые изменяют поведение
> сервера после обновления должны быть известны админу.

Они могут быть и _не_известны заранее.  Например, когда
майнтейнер предпринял достаточно разумные и адекватные меры по
переезду, но локальная специфика аукнулась.

Такие варианты остается принять как данность, предусмотрению
_все_ они подлежать не могут по определению.

>  >   Примерно так уже сделано в Debian; у нас хотелось бы вырулить
>  >   на то, информацию о чем можно получить той же почтой и
>  >   отфильтровать по порогу, причем в идеале -- иметь возможность
>  >   подвесить туда же робота (доступного в дистрибутиве), который
>  >   может, глядя на подпись и некоторые иные критерии (тот же порог
>  >   важности) -- дернуть rsync и/или apt и/или /bin/mail.
> Опа, мы кажется немного о разных вещах говорим :(

Да нет, об одной -- просто разрешаться она может в runtime или
раньше.  IMCO лучше -- как раз раньше, хотя это не меняет
необходимости отработки и runtime "по-хорошему".

> Я говорил изначально о нотификации изменений _после установки_,
> потом это уже спуталось с другой моей идеей -- нотификацией
> заинтересованых лиц в выпуске нового пакета.

Админ sisyphus-системы -- тоже лицо заинтересованное.  Или не
админ, или не системы.

>  >>       "если при обновлении меняется конфигурация, это повод
>  >>       срочно проинформировать админа, да ещё и так, чтобы он
>  >>       эту информацию потерять лишь с большим трудом мог"
>  > Ммм... *.rpmsave?
> И это тоже. Однако информацию о том, что изменилось значение
> по-умолчанию какой-то переменной оно содержать не будет, и если

Это changelog, большего требовать нельзя.

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

Технически это разве что diff.  ("установочные скрипты на прологе
или лиспе писать -- не предлагать!" :)

>  > Проблема в том, что люди, которые отвечают за базовые средства
>  > удаленного доступа и контроля/смены привилегий -- a priori
>  > полагаются более чем сведущими в вопросе.
>  > Соответственно что делать с этим вопрсом -- непонятно.
> Только подразумевать то, что даже Величайшие Гуру являются
> всего лишь живыми людьми и склонны хотя бы иногда ошибаться.

Одно из моих правил -- "человек _всегда_ имеет право на ошибку".
(применительно к другим)

> Соответственно это решается тем, что пакет должен полежать
> некоторое время в отстойнике и быть провереным (и подписаным)
> ещё некотороым количеством людей, завсиящим от уровня важности
> пакета.

Возможно.  Но для этого должно как минимум наступить осознание
своей возможности ошибаться, блин.

>  >>>> К тому же ситуация, при которой обновление может блокировать
>  >>>> работу почтовика, является одной из той, опасность которых
>  >>> Вот.  А тут добавляется еще одно требование его живости.
>  >> Сейчас эта информация просто теряется.
>  > Лог?
> В каком логе была информация о изменении структуры конфига в
> PHP?

В changelog 1:4.3.4-alt0.cvs20031017.  Сжато, но в целом --
нормально. (стоило WARNING или еще какого-нибудь принятого
ключслова?)

> Или о изменении поведения su?

Чуть ли не мимоходом в рассылке.  В режиме "я не ошибаюсь"?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]