08.06.2009 Alexey Tourbin писал:

> > > > > > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > > > > > в текущей среде, то полученный бинарный python-module-imaging теряет
> > > > > > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> > > > > Ну... таки баг и таки не просто так alt3 ?
> > > > В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).
> > > Судя по коммитам, переход alt2 -> alt3 сделан корректно, перенесением
> > > файла PIL.pth из одного подпакета в другой.
> > Да, вполне.
> > > Пересборка python-module-imaging-1.1.6-alt3 в среде с
> > > rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> > > python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> > > регрессия в rpm-build-python.
> Я посмотрел эту проблему, но пока проблемы особо не понял.
> $ hsh-install 'python2.5(PIL)'
> <13>Jun  8 07:25:23 rpmi: python-module-imaging-devel-1.1.6-alt2 installed
> $ hsh-run -- python -c 'import PIL'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named PIL
> $ 
> Пространство питоновских зависимостей -- это имена модулей, которые
> могут быть импортированы с помощью инструкции import.
> Другими словами, если пакет предоставляет зависимость 'python(foo)',
> то это должно значить, что будет работать команда python -c 'import foo'.

Это ошибка в пакете python-module-imaging: файл PIL.pth упакован в
подпакет devel. Эту ошибку swi@ пытается починить сборкой alt3. Но
натыкается на то, что пакет, содержащий и файл PIL.pth и
соответствующую директорию site-packages/PIL/ (т.е. где python -c
"import PIL" должно уже работать) таковую зависимость не предоставяет.

И это уже вторая ошибка. Я так понимаю, что сборка alt2 python2.5(PIL)
предоставляла т.к. была собрана в среде с
rpm-build-python-0.33.2-alt1. Для проверки я пересобрал
python-module-imaging-1.1.6-alt3 в среде с
rpm-build-python-0.33.2-alt1 (вместо 0.34... в Сизифе), в результате
чего python2.5(PIL) стал провайдится пакетом python-module-imaging.

Судя по changelog-у 0.33.2->0.34, была пройзведена переписка кода
python.prov.py, так что я предполагаю что в результате этого действия
Provides: теперь корректно выставлены не у всех питон-пакетов в Сизифе
(точнее у некоторых, собранных с rpm-build-python-0.34). Код изменения
я пока не смотрел.

Кроме того, хотелось бы, чтобы при сборке пакетов проверялось, реально
ли пакет, содержащий *.pth-файл, может обеспечить python -c "import
foo", чтобы застраховаться от подобный ошибок упаковки.

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team