[devel] проясните ситуацию с php

[devel] проясните ситуацию с php

[Andrew Kornilov]

Всем привет.

Мне тут на днях приехал отчет от QA Team Robot для двух пакетов:

Package: php-eaccelerator-0.9.5-alt1
Packager: Andrew Kornilov <hiddenman@altlinux>
Status: i586 rebuild failed.
Please investigate.

Why:

Reading Package Lists...
Building Dependency Tree...
E: Version ='1:4.4.4-alt2' for 'php-devel' was not found

В соответствии с нашей системой сборки, у нас прописываются жестко версии php в spec (http://wiki.sisyphus.ru/devel/php/rebuildPHP   вот как нужно что-то пересобирать). Два вопроса:
1. Зачем так сделано все-таки?  Это действительно решает какие-то проблемы?
2. Нельзя ли неким роботом пересобрать все, что использует php-devel, если он обновляется? И если уже не собирается, тогда присылать отчет об ошибках? Я не понимаю, зачем мне нужно сейчас где-то обновлять php-devel и php5-devel, собирать заново src.rpm, потом засовывать его в свой хашер, подписывать и отправлять этот пакет опять в incoming. Если я кроме изменения версии ничего не делаю? Какой-то, извините, мартышкин труд. Ну или я чего-то не понимаю (вполне возможно, знающие поймут :-)

Re: [devel] проясните ситуацию с php

[gns]

достаточно по идее собрать src.rpm в системе с установленным свежим
rpm-build-php. это *чуть* проще чем мы делали =)

2007/3/20, Andrew Kornilov <hiddenman@altlinux.ru>:
> Всем привет.
>
> Мне тут на днях приехал отчет от QA Team Robot для двух пакетов:
>
> Package: php-eaccelerator-0.9.5-alt1
> Packager: Andrew Kornilov <hiddenman@altlinux>
> Status: i586 rebuild failed.
> Please investigate.
>
> Why:
>
> Reading Package Lists...
> Building Dependency Tree...
> E: Version ='1:4.4.4-alt2' for 'php-devel' was not found
>
> В соответствии с нашей системой сборки, у нас прописываются жестко версии
> php в spec (http://wiki.sisyphus.ru/devel/php/rebuildPHP   вот как нужно
> что-то пересобирать). Два вопроса:
> 1. Зачем так сделано все-таки?  Это действительно решает какие-то проблемы?
> 2. Нельзя ли неким роботом пересобрать все, что использует php-devel, если
> он обновляется? И если уже не собирается, тогда присылать отчет об ошибках?
> Я не понимаю, зачем мне нужно сейчас где-то обновлять php-devel и
> php5-devel, собирать заново src.rpm, потом засовывать его в свой хашер,
> подписывать и отправлять этот пакет опять в incoming. Если я кроме изменения
> версии ничего не делаю? Какой-то, извините, мартышкин труд. Ну или я чего-то
> не понимаю (вполне возможно, знающие поймут :-)
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] проясните ситуацию с php

[Andrew Kornilov]

gns@altlinux.ru wrote:
> достаточно по идее собрать src.rpm в системе с установленным свежим
> rpm-build-php. это *чуть* проще чем мы делали =)
>   
Осталось выяснить, зачем это всё :) legion в jabber-е мне сказал, что 
только я, как майнтейнер, смогу проверить работоспособность этих модулей 
с новым php. Я ничего проверять и не собирался, если честно. Пока не 
придёт время поставить новую систему или еще по каким-то 
обстоятельствам, действительно обоснованным для меня.

Re: [devel] проясните ситуацию с php

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

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

On Tue, Mar 20, 2007 at 08:49:21PM +0200, Andrew Kornilov wrote:
>> достаточно по идее собрать src.rpm в системе с установленным свежим
>> rpm-build-php. это *чуть* проще чем мы делали =)
AK> Осталось выяснить, зачем это всё :) legion в jabber-е мне сказал, что 
AK> только я, как майнтейнер, смогу проверить работоспособность этих модулей 
AK> с новым php. Я ничего проверять и не собирался, если честно. Пока не 
AK> придёт время поставить новую систему или еще по каким-то 
AK> обстоятельствам, действительно обоснованным для меня.

Для тех модулей, которые не являются протоколами элементарно можно
написать набор unit-test'ов. Которые проверят куда лучше чем любой
мантейнер.

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

http://freesource.info
----------------------------------------------------------------------------
sim как jabber-клиент - то еще извращение.
		-- wrar in smoke-room@

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

Re: [devel] проясните ситуацию с php

[Aleksey Avdeev]

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

gns@altlinux.ru пишет:
> достаточно по идее собрать src.rpm в системе с установленным свежим
> rpm-build-php. это *чуть* проще чем мы делали =)

  В php-mcrypt я делаю несколько по другому: в спек (см.
<http://git.altlinux.org/people/solo/packages/?p=php-mcrypt.git;a=blob;f=php-mcrypt.spec;h=2475691bca2b669cc52695a7067194216ed01edd;hb=c8532a21a21ea16ef117907a82c37448442c3f91>)
добавлина возможность явно указать версию через паметры. Это позволяет
слать rpmbuild -bs с явным указанием нужной версии php (при начии
rpm-build-php _другой_ версии) и отправить полученный пакет в haser, для
получения окончательного результата.

> 
> 2007/3/20, Andrew Kornilov <hiddenman@altlinux.ru>:
>> Всем привет.
>>
>> Мне тут на днях приехал отчет от QA Team Robot для двух пакетов:
>>
>> Package: php-eaccelerator-0.9.5-alt1
>> Packager: Andrew Kornilov <hiddenman@altlinux>
>> Status: i586 rebuild failed.
>> Please investigate.
>>
>> Why:
>>
>> Reading Package Lists...
>> Building Dependency Tree...
>> E: Version ='1:4.4.4-alt2' for 'php-devel' was not found
>>
>> В соответствии с нашей системой сборки, у нас прописываются жестко версии
>> php в spec (http://wiki.sisyphus.ru/devel/php/rebuildPHP   вот как нужно
>> что-то пересобирать). Два вопроса:
>> 1. Зачем так сделано все-таки?  Это действительно решает какие-то проблемы?
>> 2. Нельзя ли неким роботом пересобрать все, что использует php-devel, если
>> он обновляется? И если уже не собирается, тогда присылать отчет об ошибках?
>> Я не понимаю, зачем мне нужно сейчас где-то обновлять php-devel и
>> php5-devel, собирать заново src.rpm, потом засовывать его в свой хашер,
>> подписывать и отправлять этот пакет опять в incoming. Если я кроме изменения
>> версии ничего не делаю? Какой-то, извините, мартышкин труд. Ну или я чего-то
>> не понимаю (вполне возможно, знающие поймут :-)
>>

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] проясните ситуацию с php

[Andrew Kornilov]

Aleksey Avdeev wrote:
>> достаточно по идее собрать src.rpm в системе с установленным свежим
>> rpm-build-php. это *чуть* проще чем мы делали =)
>>     
>
>   В php-mcrypt я делаю несколько по другому: в спек (см.
> <http://git.altlinux.org/people/solo/packages/?p=php-mcrypt.git;a=blob;f=php-mcrypt.spec;h=2475691bca2b669cc52695a7067194216ed01edd;hb=c8532a21a21ea16ef117907a82c37448442c3f91>)
> добавлина возможность явно указать версию через паметры. Это позволяет
> слать rpmbuild -bs с явным указанием нужной версии php (при начии
> rpm-build-php _другой_ версии) и отправить полученный пакет в haser, для
> получения окончательного результата.
>   

Создали инструменты для борьбы с другими инструментами  :)

Re: [devel] проясните ситуацию с php

[Aleksey Avdeev]

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

Andrew Kornilov пишет:
> Aleksey Avdeev wrote:
> 
>>>достаточно по идее собрать src.rpm в системе с установленным свежим
>>>rpm-build-php. это *чуть* проще чем мы делали =)
>>>    
>>
>>  В php-mcrypt я делаю несколько по другому: в спек (см.
>><http://git.altlinux.org/people/solo/packages/?p=php-mcrypt.git;a=blob;f=php-mcrypt.spec;h=2475691bca2b669cc52695a7067194216ed01edd;hb=c8532a21a21ea16ef117907a82c37448442c3f91>)
>>добавлина возможность явно указать версию через паметры. Это позволяет
>>слать rpmbuild -bs с явным указанием нужной версии php (при начии
>>rpm-build-php _другой_ версии) и отправить полученный пакет в haser, для
>>получения окончательного результата.
>>  
> 
> 
> Создали инструменты для борьбы с другими инструментами  :)

  Ага. :-)

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] проясните ситуацию с php

[Konstantin A. Lepikhov]

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

Hi Andrew!

Tuesday 20, at 08:33:43 PM you wrote:

<skip>
> В соответствии с нашей системой сборки, у нас прописываются жестко версии php в spec (http://wiki.sisyphus.ru/devel/php/rebuildPHP   вот как нужно что-то пересобирать). Два вопроса:
> 1. Зачем так сделано все-таки?  Это действительно решает какие-то проблемы?
да, например совместимости модулей по ABI (php'шники периодически
умудряются ее ломать даже в 4.x ветке). Также пересборка требуется при
обновлении suhosin патча (не extension!), т.к. только в этом случае можно
гарантировать, что модуль будет слинкован с новой php-libs. 

> 2. Нельзя ли неким роботом пересобрать все, что использует php-devel, если он обновляется? И если уже не собирается, тогда присылать отчет об ошибках? Я не понимаю, зачем мне нужно сейчас где-то обновлять php-devel и php5-devel, собирать заново src.rpm, потом засовывать его в свой хашер, подписывать и отправлять этот пакет опять в incoming. Если я кроме изменения версии ничего не делаю? Какой-то, извините, мартышкин труд. Ну или я чего-то не понимаю (вполне возможно, знающие поймут :-)
пересобирать ядерные модули тоже мартышкин труд, однако их пересобирают.
Скрипты по пересборке приветствуются ;)

-- 
WBR et al.

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

Re: [devel] проясните ситуацию с php

[Andrew Kornilov]

Konstantin A. Lepikhov wrote:
> да, например совместимости модулей по ABI (php'шники периодически
> умудряются ее ломать даже в 4.x ветке). Также пересборка требуется при
> обновлении suhosin патча (не extension!), т.к. только в этом случае можно
> гарантировать, что модуль будет слинкован с новой php-libs. 
>
>   
Я пока не понял, как явно указанная версия php-devel в этом помогает.
>> 2. Нельзя ли неким роботом пересобрать все, что использует php-devel, если он обновляется? И если уже не собирается, тогда присылать отчет об ошибках? Я не понимаю, зачем мне нужно сейчас где-то обновлять php-devel и php5-devel, собирать заново src.rpm, потом засовывать его в свой хашер, подписывать и отправлять этот пакет опять в incoming. Если я кроме изменения версии ничего не делаю? Какой-то, извините, мартышкин труд. Ну или я чего-то не понимаю (вполне возможно, знающие поймут :-)
>>     
> пересобирать ядерные модули тоже мартышкин труд, однако их пересобирают.
> Скрипты по пересборке приветствуются ;)
>
>   

Думаю, не в скриптах проблема. Если в сизиф приезжает новая библиотека, 
то логично пересобрать все пакеты, которые используют её для сборки и 
сразу будут видны проблемы. Вероятно, что-то такое и происходит 
регулярно, когда пересобирается весь сизиф.
Но вот зачем в php.spec нужно прописывать явно версию текущего php-devel 
и потом заниматься этим сизифовым трудом? :)

Re: [devel] проясните ситуацию с php

[Alexey I. Froloff]

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

* Andrew Kornilov <hiddenman@> [070320 21:42]:
> 1. Зачем так сделано все-таки?  Это действительно решает
> какие-то проблемы?
Ну, для "стандартных" модулей php новый релиз php-devel может
означать новые исходники этого модуля, потому как они в php-devel
лежат.  В таком случае должен быть собран новый пакет.

Для "сторонних" модулей, возможно, такая строгая зависимость и не
нужна.  С другой стороны, учитывая общую невменяемость апстрима,
может сломаться API/ABI, не создавая при этом видимых unmet'ов
(поможет только qa-robot).

Наверно лучше перебдеть, чем недобдеть, такое моё мнение.

P.S. На тему "пересобирать всё при изменении libfoo-devel"...
Новая версия glibc - пересборка всего сизифа.  5G обновлений
только на i586.

-- 
Regards,
Sir Raorn.

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

Re: [devel] проясните ситуацию с php

[Andrew Kornilov]

Alexey I. Froloff wrote:
> Ну, для "стандартных" модулей php новый релиз php-devel может
> означать новые исходники этого модуля, потому как они в php-devel
> лежат.  В таком случае должен быть собран новый пакет.
>   
Про "встроенные" согласен. Хотя встроенные, скорее всего, собирает тот 
же человек, кто собирает сам php и php-devel и наверняка это 
автоматизировано у него :)
> Для "сторонних" модулей, возможно, такая строгая зависимость и не
> нужна.  С другой стороны, учитывая общую невменяемость апстрима,
> может сломаться API/ABI, не создавая при этом видимых unmet'ов
> (поможет только qa-robot).
>   
Так и не про анметы речь, а про простую пересборку. Оно или соберется 
или нет. В случае если соберется и не будет работать, "мгновенная" 
пересборка даже лучше, пользователь раньше пакет получит :)
> Наверно лучше перебдеть, чем недобдеть, такое моё мнение.
>
>   
А в чем в данном случае "перебдение"? В выкидывании из сизифа всех 
модулей при появлении нового php?
> P.S. На тему "пересобирать всё при изменении libfoo-devel"...
> Новая версия glibc - пересборка всего сизифа.  5G обновлений
> только на i586.
>   
Нужно искать компромиссы. Делать просто контрольную пересборку, без 
изменения пакетной базы (что и происходит, видимо, регулярно). Да и 
вообще, я про php спрашивал :)

Re: [devel] п©я─п╬я▐я│п╫п╦я┌п╣ я│п╦я┌я┐п╟я├п╦я▌ с php

[Aleksey Avdeev]

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

Andrew Kornilov пишет:
> Alexey I. Froloff wrote:
> 
>>Ну, для "стандартных" модулей php новый релиз php-devel может
>>означать новые исходники этого модуля, потому как они в php-devel
>>лежат.  В таком случае должен быть собран новый пакет.
>>  
> 
> Про "встроенные" согласен. Хотя встроенные, скорее всего, собирает тот 
> же человек, кто собирает сам php и php-devel и наверняка это 
> автоматизировано у него :)

  Не совсем.

  Возьмём для примера тот-же php-mcrypt: для php он является
"стандартным" но когда он мне потребовался -- у нас он не собирался,
потому и был поднят мной. (В php5 -- он собирается вместе с остальными,
чему я рад. :-))

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] проясните ситуация▌ с php

[Andrew Kornilov]

Aleksey Avdeev wrote:
>> Про "встроенные" согласен. Хотя встроенные, скорее всего, собирает тот 
>> же человек, кто собирает сам php и php-devel и наверняка это 
>> автоматизировано у него :)
>>     
>
>   Не совсем.
>
>   Возьмём для примера тот-же php-mcrypt: для php он является
> "стандартным" но когда он мне потребовался -- у нас он не собирался,
> потому и был поднят мной. (В php5 -- он собирается вместе с остальными,
> чему я рад. :-))
>   
Да, я  примерно в курсе, была подобная ситуация с php-imap, но потом её 
тоже кто-то решил.
Вообще неплохо бы увидеть список "стандартных" модулей, которые у нас не 
собираются. Может "мужики-то и не знают", думают, что всё в порядке.

Re: [devel] проясните ситуацию с php

[Alexey I. Froloff]

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

* Andrew Kornilov <hiddenman@> [070324 01:05]:
> Про "встроенные" согласен. Хотя встроенные, скорее всего, собирает тот 
> же человек, кто собирает сам php и php-devel
Совсем необязательно.

> Так и не про анметы речь, а про простую пересборку. Оно или соберется 
> или нет. В случае если соберется и не будет работать, "мгновенная" 
> пересборка даже лучше, пользователь раньше пакет получит :)
Читаем ещё раз:

> > Для "сторонних" модулей, возможно, такая строгая зависимость и не
> > нужна.

Ключевое слово тут - "возможно".  Вот у меня как раз нажревает
один php модуль, на нём и потренируюсь ;-)

> А в чем в данном случае "перебдение"? В выкидывании из сизифа всех 
> модулей при появлении нового php?
Да почему выкидывании-то?  Пакет _выкидывается_ после 10-и
неудачных пересборок.

> Нужно искать компромиссы. Делать просто контрольную пересборку, без 
> изменения пакетной базы (что и происходит, видимо, регулярно). Да и 
> вообще, я про php спрашивал :)
"Все пакеты равны, но некоторые равнее других".

-- 
Regards,
Sir Raorn.

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

Re: [devel] проясните ситуацию с php

[Andrew Kornilov]

Alexey I. Froloff wrote:
>> Про "встроенные" согласен. Хотя встроенные, скорее всего, собирает тот 
>> же человек, кто собирает сам php и php-devel
>>     
> Совсем необязательно.
>
>   
Ну понятно, что необязательно. Но вполне логично. Без модулей php все 
равно только в качестве генератора бесконечного цикла нужен.
>> Так и не про анметы речь, а про простую пересборку. Оно или соберется 
>> или нет. В случае если соберется и не будет работать, "мгновенная" 
>> пересборка даже лучше, пользователь раньше пакет получит :)
>>     
> Читаем ещё раз:
>
>   
>>> Для "сторонних" модулей, возможно, такая строгая зависимость и не
>>> нужна.
>>>       
>
> Ключевое слово тут - "возможно".  Вот у меня как раз нажревает
> один php модуль, на нём и потренируюсь ;-)
>   
Собирать-то в первый раз сейчас удобно, да, больше спасибо создателю. 
Как в perl макросы (описали бы их еще)
>   
>> А в чем в данном случае "перебдение"? В выкидывании из сизифа всех 
>> модулей при появлении нового php?
>>     
> Да почему выкидывании-то?  Пакет _выкидывается_ после 10-и
> неудачных пересборок.
>   
В самом первом сообщении я писал, что мне пришло. Никаких пересборок не 
было, точнее, видимо были холостые попытки, потому что в spec прописана 
конкретная версия php-devel. И вся пересборка заканчивалась на стадии 
сбора нужных пакетов в хашере.
>> Нужно искать компромиссы. Делать просто контрольную пересборку, без 
>> изменения пакетной базы (что и происходит, видимо, регулярно). Да и 
>> вообще, я про php спрашивал :)
>>     
> "Все пакеты равны, но некоторые равнее других".
>
>   
Кстати, glibc-devel нужен далеко не всему репозитарию.

Re: [devel] проясните ситуацию с php

[Konstantin A. Lepikhov]

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

Hi Andrew!

Saturday 24, at 12:19:08 AM you wrote:

> > Ключевое слово тут - "возможно".  Вот у меня как раз нажревает
> > один php модуль, на нём и потренируюсь ;-)
> >   
> Собирать-то в первый раз сейчас удобно, да, больше спасибо создателю. 
> Как в perl макросы (описали бы их еще)
А что там такого описывать? В /etc/rpm/macros.d/php все и так видно. У нас
же не python ;)

..
> В самом первом сообщении я писал, что мне пришло. Никаких пересборок не 
> было, точнее, видимо были холостые попытки, потому что в spec прописана 
> конкретная версия php-devel. И вся пересборка заканчивалась на стадии 
> сбора нужных пакетов в хашере.
Это правильно - иначе процесс пересборки становится бессмысленным - что
толку что он пересоберет модуль с актуальным в данный момент php-devel -
ведь это лишь скроет возоможную ошибку, а не уведомит maninainer'а, о том,
что пора зачесаться и пересобрать свой модуль (робот не может исправлять
ошибки, он только указывает на regression).

...
> Кстати, glibc-devel нужен далеко не всему репозитарию.
это вы о чем?

-- 
WBR et al.

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